Excellent article on why a Repository Manager is crucial for software development process. Makes the case that not using a Repository Manager is the cause of many anti-patterns. It could be that the Repository is the next essential besides the VCS in development best practices.
The article is using Maven as a case in point and also it is selling a product (nothing wrong with that) so perhaps one could be a little wary. However there are other dependency managers like Ivy which are used by other Build systems like Gradle available.
I have seen places that do not use a Software Configuration Managment (SCM) Version Control System (VCS). And, then there are places that use a VCS incorrectly; as this article points out the VCS becomes an ad hoc file store for everything. I remember one place where our partner gave us access to their SCM to download a project source, and we got everything! They had application executables, utilities, documents, binaries and other things like their Office apps and other tool chains, which had nothing to do with the project we wanted the source of. Someone must have accidentally imported their whole PC into CVS, yikes.
Enter the Repository which, I believe, first became “popular” with the introduction of Maven. When I tried to introduce use of an internal Repository into a former company I got push back: “It’s very easy to just put one’s jars and dependent binaries into version control” or “Who needs that Repository play toy stuff!” Oh well. In that situation, it was probably the best decision, there is initial complexity in adopting any tool that aims to reduce complexity.
Is just using Mavan or Gradle with an internal Repository as proxy to external ones enough Repository Management (which Sonatype calls stage one: Proxying Remote Repositories) or does one have to use a full blown Repository Manager subsystem? Why does using the internal Repository for one’s own output destination require a Repository Manager (which Sonatype calls ‘stage two’)? The Maven site has this to say:
Aside from the benefits of mediating access to remote repositories, a repository manager also provides something essential to full adoption of Maven. Unless you expect every member of your organization to download and build every single internal project, you will want to provide a mechanism for developers and departments to share both SNAPSHOT and releases for internal project artifacts. A Maven repository manager provides your organization with such a deployment target. Once you install a Maven repository manager, you can start using Maven to deploy snapshots and releases to a custom repository managed by the repository manager. Over time, this central deployment point for internal projects becomes the fabric for collaboration between different development teams. — Repository Management with Maven Repository Managers.
If you don’t think this is important you probably have not been on a project where disasters like xxx.jar was sent to a customer and we don’t know what version it is and who made it. You know, using version numbers as part of binary files would defeat the purpose of using a VCS no?
On a side note: Why did the Java development community develop its own repository system when there were plenty out there such as the application-level package systems used by the Linux community?
Why Do I Need a Repository Manager?: link
Maven Repository Manager Feature Matrix: link
Continuous Integration: http://en.wikipedia.org/wiki/Continuous_integration
- maven-tomcat7-plugin not extracting the war file
- Groovy script to bootstrap a Gradle Project
- Current Git repo branch name using Groovy
- Continuous Testing while developing, CDT?
- Jenkins CI Server is great