Nexus is the next generation of the popular Proximity repository manager software for use with Apache Maven. This is the first public release of Nexus, and I believe it marks an important milestone in the practice of building software. I'm not what you might call an early adopter when it comes to software. In the vast majority of applications I use, I know how to use less than 25% of the features. A long time ago, I realized I was spending too much time trying to keep the technology (software, hardware, configurations, whatever) going to get anything done in a reasonable amount of time. Today, my point of view is very pragmatic. For any new application, I generally ask myself what the software does that will make my life easier in concrete terms, and can I really depend on it to do these things reliably and with little or no babysitting. For instance, I generally don't use the milestone releases of my IDE of choice, Eclipse; they're simply not stable enough for me to be able to focus on the software I'm ...

NOTE: I’m cross-posting this article on both my Build Chimp and Sonatype blogs. I mentioned recently in part one that using AspectJ to support backward compatibility for Maven is proving a great way to keep the main API free of the clutter associated with supporting old method signatures and classpath structures (for instance, making sure plexus-utils is always available, as it once was from Maven’s core). Today, I’d like to shed a little light on some other aspecting work I’ve done that bridges two previously unconnected manager components inside the Plexus container, to support active component collections. Active component collections are maps, lists, etc. of Plexus components which can themselves be injected as requirements into yet another component when it traverses the CompositionPhase, the phase of the Plexus component lifecycle where dependency injection typically takes place. Without getting too far into the details, these collections are not real components in the Plexus ...

NOTE: I’m cross-posting this article on both my Build Chimp and Sonatype blogs. Recently, I’ve been spending a lot of time hacking on Maven trunk (what will become Maven 2.1 eventually), and trying to tackle some of the larger problems with plugin- and extension-loading, and planning out the order of mojo execution for a given build ahead of time. While we’ve had to some really encouraging success in addressing these sorts of broad problems (along with artifact resolution, which Jason van Zyl has been paying a lot of attention to), we’ve run into other, stickier problems relating to backward compatibility. You see, some of the more advanced Maven plugins out there make use of some pretty deeply buried Maven components to do their jobs. This means that changing the APIs of some of these deep components will break those plugins, resulting in NoSuchMethodErrors. Part of the root problem here is allowing plugins to lookup any old component in the system that they want to; another part is ...