Maven and Nexus: Not All Pain is Bad
Right after using Nexus to solve my problem with the Amazon SES dependency imbroglio, I had occasion to make a new Java EE 6 project using the Weld archetype, and, lo and behold, there was more pain to grind through. Clearly, it‘s a good sign when a tool (in this case Nexus) ends up feeling more like a life preserver than another complicated pile of crap that prolonged the smoldering pyre.
Frankly, what came out smelling like rotten fish in this was just the usual: the ‘open‘ community that doesn‘t seem obliged to patch the potholes on the main arteries that span its territories. Arquillian uses profiles to support its runtime configurations. Once the compound project was put together and code was dragged in from another project (that included some tests), we moved the profile definitions into the parent pom, then went to one of the jar projects and set the profile name in the eclipse preferences and the build broke. Now, here is one little nit against Maven: the newer format for unsatisfied dependencies leaves a lot to be desired. When Maven is not satisfied, it spits out this long line of dependencies, usually with the error at the end (rather than in a list that would mirror something like a stack trace). Quick nit on eclipse: once one of the dependencies fails, the whole build situation goes to hell and eclipse paints a picture of utter pandemonium, listing missing items that you know you have (e.g. hamcrest, junit, etc.). There‘s no way for you to look at the list of hundreds of items and know which one is the missing keystone. Anyway, in my case, it was a sun dependency called istack.
What happened next was kind of interesting: I found a thread, and in the middle of it, the proposed solution was to configure another jboss repo proxy in nexus for snapshot releases. That was not quite so simple, because it turned out that the pom was missing (see the links below). Eventually, that worked for me. But then I frittered away a lot of time trying to get the tests to run. I guess I didn‘t realize that Arquillian doesn‘t support JBoss 7 yet: soon as I started 6 and used the arq-jbossas-remote profile, the tests passed.
On one of the other guy‘s machines, he was unable to pull another dependency: trove. That turned into another sucky slough, which was another case of the same thing: found a thread (below) where someone solved it by adding a proxy to Nexus for the deprecated dependencies.
The best thing about all this stuff is that it feels a lot more permanent. While the trove thing was going on for a while, I came back to the guy who was stuck trying to ram some things into his settings.xml file. I was like ‘dude, I‘m going to go bag groceries before we go back to this kind of nonsense: each person jerryrigging their own sled.‘ Nexus should have come years ago, it is the missing link. There are still a lot of great things they could do with this thing. It‘s got to occur to someone that a declarative interface like this, which is, unlike Ant, tied to a structured ‘model,‘ but then, it‘s also kind of silly for a product (Arquillian) to need a bunch of things from its own repos (jboss) and for each person who tries to use it to have to shepherd this whole process. The inexcusable parts here are the sloppy stuff like missing poms, etc. But you have to think that maybe there‘s one more level of abstraction that might make sense, e.g. some format that you could click on that would add required configs to your nexus server. That could be done through a services interface. You could even imagine Nexus providing product searches, e.g., search for Arquillian, find it, click to set it up, and it would add the required repository mappings, and/or path mappings. Would have to have some smarts about it that would be able to add to existing configured resources, but then, the URLs are unique, probably not that complicated. Meantime, Nexus is awesome. Oh, and I got the rest of the team into the ui using their Mac OS X account creds (see below).
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)