So I’ve been continuing to play with my CDI-and-linking idea, and central to it is the ability to locate CDI “modules” Out There In The World™. The world, in this case, is Maven Central. Well, or perhaps a local mirror of it. Or maybe your employer’s private Nexus repository fronting it. Oh jeez, we’re going to have to really use Maven’s innards to do this, aren’t we?
As noted earlier, even just figuring out what innards to use is hard. So I figured out that the project formerly known as Æther, Maven Artifact Resolver, whose artifact identifier is maven-resolver, is the one to grab.
Then, upon receiving it and opening it up, I realized that the whole thing is driven by Guice—or, if you aren’t into that sort of thing, by a homegrown service locator (which itself is a service, which leads to all sorts of other Jamie Zawinski-esque questions).
The only recipes left over are from the old Æther days and require a bit of squinting to make work. They are also staggeringly complicated. Here’s a gist that downloads the (arbitrarily selected)
org.microbean:microbean-configuration-cdi:0.1.0 artifact and its transitive,
compile-scoped dependencies, taking into account local repositories, the user’s Maven
~/.m2/settings.xml file, active Maven profiles and other things that we all take for granted:
That seems like an awful lot of work to have to do just to get some stuff over the wire. It also uses the cheesy homegrown service locator which as we all know is not The Future™.
For my purposes, I wanted to junk the service locator and run this from within a CDI 2.0 environment, both because it would be cool and dangerous and unexpected, and because the whole library was written assuming dependency injection in the first place.
So I wrote a portable extension that basically does the job that the cheesy homegrown service locator does, but deferring all the wiring and validation work to CDI, where it belongs.
As if this whole thing weren’t hairy enough already, a good number of the components involved are Plexus components. Plexus was a dependency injection framework and container from a ways back now that also had a notion of what constituted beans and injection points. They called them components and requirements.
So a good portion of some of the internal Maven objects are annotated with
Requirement. These correspond roughly—very, very roughly—to bean-defining annotations and injection points, respectively.
So I wrote two portable extension methods. One uses the
role element from
Component to figure out what kind of
Typed annotation to add to Plexus components. The other turns a
Requirement annotation with a
hint into a valid CDI injection point with an additional qualifier.
(Along the way, these uncovered MNG-6190, which indicates that not very many people are even using the Maven Artifact Resolver project in any way, or at least not from within a dependency injection container, which is, of course, how it is designed to be used. That’s a shame, because although it is overengineered and fiddly to the point of being virtually inscrutable, it is, as a result, perhaps, quite powerful.)
Then the rest of the effort was split between finding the right types to add into the CDI container, and figuring out how to adapt certain Guice-ish conventions to the CDI world.
The end result is that the huge snarling gist above gets whittled down to five or so lines of code, with CDI doing the scope management and wiring for you.
This should mean that you can now relatively easily incorporate the guts of Maven into your CDI applications for the purposes of downloading and resolving artifacts on demand. See the
microbean-maven-cdi project for more information. Thanks for reading.