13949712720901ForOSX Apple should release a version of Java6 for OS X, or at least participate in an open discussion of why they won't. If you want to know what the above alpha-numeric word (?) is, check this out.

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 ...

Imagine this scenario: you've got a directory full of jar files, and your build is failing because it's missing some classes that are in one of them. You're not sure which; only that the missing classes are in here somewhere. I've been running into this problem a lot lately, as I try to convert a series of old Ant builds over to Maven. At times, I've found that the jar name doesn't even come close to indicating whether it contains the key classes I need to make my build start working. To address this problem, I've started a short Ruby script that I'm tentatively calling jargrep.rb. Before I show you this, please remember that I'm a little green when it comes to Ruby, so there may be some elegant one-liner that I'm missing here or there...and it may look decidedly Java-ish to the "native" Ruby programmer. Oh, and I'm not looking to win any architectural or OO-design awards here; I only needed a script to scratch a very persistent itch. Finally, this script is lacking a lot of polish when it comes ...

Going through the javablogs blogroll today, I came across this. Hmm, 20 feet long? I think I might just have enough room out behind the garage for that... Too bad there's no way GRU's shitty grid could support it. (Yeah, like I could afford to have one of those...or even to pay the electrical bill on one of those...)