If you’ve read any of my previous writing, you will have noticed I’m a fan of services that don’t involve me directly building and managing a server anywhere. Call them “Serverless”, call them “X-as-a-service”, the crux for me is that I can focus on using the service and not worry much about where and how it runs.

CodeArtifact falls squarely into that category for me. I recently wrote about building a  serverless CI/CD pipeline for Go code. For Go, the ultimate output of the pipeline was an executable published into an S3 bucket. For Java code, this approach gets a bit clunky.

Like it or not, the de-facto standard for building and packaging Java code for many years has been Maven. Alternatives like Gradle chip away at it’s dominance, but Maven still wears the crown. I don’t think anyone on the planet can say that they like Maven, but for all of it’s many annoyances it gets the job done reliably and repeatably.

In the Java world, the automatic de-facto development infrastructure for a team looks pretty well the same as it has for over a decade: Eclipse or Intellij on the desktop, against a Maven project. Some sort of code repository, usually Gitlab or Github. Jenkins or Hudson to do the actual CI builds (even though there are much nicer solutions now), and an artifact repository to store built JARs in and allow them to be shared. Again, the de-facto standard for many years has been the well-regarded Artifactory from JFrog, and it’s this component in the stack that CodeArtifact replaces.

#serverless #aws #codeartifact