Nexus: New Day in Dependency Management
I switched to Maven in 2005, not long after 2 had come out. Ant just ran out of gas for me, despite a lot of people trying to throw it a life preserver. No question, years later, the biggest hassle of Maven has been the corporate repository that is required. This is kind of an interesting case from a Lean perspective because on the face of it, there should be no reason for this. Making the repo is super simple. And then access control involves just getting the cert and adding it to your keystore. The first problem with the keystore crap is you have to do it at the command line, then worse than that, the keystore, by default, is in the JDK, so when you install a new JDK version, you have to redo the cert. Ultimately, we adopted an approach where we had a trust store file in the maven directory so changing versions did not disrupt it. Not that big a deal.
I had used Archiva, whose main appeal was just to make it possible to add artifacts without having to use the hellish command line interface to do so. Recently, Archiva was not working in my tomcat installation on my mini server, so I went looking and found Nexus.
Nexus is a lot more ambitious. Even the early docs for Maven 2 said that your goal should be to make your corporate repo have all the files your projects need. We never did that, because it was not really easy to do. Nexus makes that not only easy, but transparent. I got it setup, and even more importantly, I got it hooked up to the Mac OS X Server edition‘s LDAP server (Open Directory) and then mert came in and setup the proxying. However, we didn‘t go through the poms and sanitize them.
For anyone who has ever used MoSCoW, the W is often the ugly stepsister, yet I think one of the marks of really great programmers is their instinct for opportunistic (there is a good connotation) changes. In part, because it requires creativity. Last night, I was wrestling again with some dependency issues from having added Amazon‘s aws-sdk (transitive dependency not being found on the jenkins server). Found a thread where the resolution was to add a path to nexus. Decided I would solve this problem and perform the sanitization of the poms finally.
It was remarkably painless. And the best thing about it is I think builds are going to be much faster for everyone. Also, issues like this can be resolved once and without any fiddling in the individual poms.
The only thing left on my Nexus list is to see if we can get rid of the certs and instead have users auth for non-public artifacts using LDAP. In other words, we are building things on Jenkins that are going into our corporate repo that are not available to the world. Can we just have those inNexus and then auth to gain access to them? Seems like it should work.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)