This post is a part of a tiny series I'm doing on why we use Maven, and you should too.
Previous posts:
Many projects that have grown over time will become too large to easily work with. The workspace gets too many classes, the IDE slows down and the build takes too long. If the developers focus on separating the concerns of the classes into packages of functionality, these packages can be organized into modules. As the contract and concern of a module becomes more defined, its rate of change will fall to a lower frequency than the rest of the project.
Once a module's activity has slowed down sufficiently, you can retire it into an external project, build a JAR-file from it and use this ready-built artifact as a classpath element for building and running the software instead. If changes occur later on, you can re-build the JAR-file.
Examples on where this might be appropriate:
Maven eases the work of maintaining such dependencies. As projects "subscribe" to their dependencies, they pull in the latest appropriate JAR-files automatically (snapshots) or by choice of versioned artifact. In an environment with a continuous integration server and a maven repository, the library developers need only commit their changes, and the artifact will be automatically built, deployed, and pulled into the depending project. A good term to describe this setup is Enterprise Maven Infrastructure (see this link for more information on how to actually implement this),
Again, understand that it is better to subscribe to your dependencies than to push them in.
I could go on on how bad it is to work on a project with a single huge build, but I imagine most developers out there are either struggling with it right now, or have done so some time in the past. There are many reasons why you want to break out modules of your project for architectural and code-design/quality reasons, but in this post I chose just to focus on the basic reasons. I came across one video from SonaType that illustrates this situation very well, so if you didn't get it from reading this post, please take a look at it (although the fancy staging functionality of Nexus is not that important, nor the point of this post).
Previous posts:
- Introduction: Why you should use Maven
- Reason 1: Get your libs-folder out of SVN
- Reason 2: Clean up your JAR-files
Many projects that have grown over time will become too large to easily work with. The workspace gets too many classes, the IDE slows down and the build takes too long. If the developers focus on separating the concerns of the classes into packages of functionality, these packages can be organized into modules. As the contract and concern of a module becomes more defined, its rate of change will fall to a lower frequency than the rest of the project.
Once a module's activity has slowed down sufficiently, you can retire it into an external project, build a JAR-file from it and use this ready-built artifact as a classpath element for building and running the software instead. If changes occur later on, you can re-build the JAR-file.
Examples on where this might be appropriate:
- Low level libraries and utilities, much like Java's own java.util package only changes every other year or so.
- Contracts or adapters around external services, because integration with 3rd parties require stable data-formats.
Maven eases the work of maintaining such dependencies. As projects "subscribe" to their dependencies, they pull in the latest appropriate JAR-files automatically (snapshots) or by choice of versioned artifact. In an environment with a continuous integration server and a maven repository, the library developers need only commit their changes, and the artifact will be automatically built, deployed, and pulled into the depending project. A good term to describe this setup is Enterprise Maven Infrastructure (see this link for more information on how to actually implement this),
Again, understand that it is better to subscribe to your dependencies than to push them in.
- Library developers do not have to deploy their artifacts to all clients
- Clients keep the control of which libraries they use, in which version
- Easier to maintain transitive dependencies (see my previous post)
- Getting newer versions is easy
I could go on on how bad it is to work on a project with a single huge build, but I imagine most developers out there are either struggling with it right now, or have done so some time in the past. There are many reasons why you want to break out modules of your project for architectural and code-design/quality reasons, but in this post I chose just to focus on the basic reasons. I came across one video from SonaType that illustrates this situation very well, so if you didn't get it from reading this post, please take a look at it (although the fancy staging functionality of Nexus is not that important, nor the point of this post).
Comments
Post a Comment