A Corollary to Sleeping On It
Just "sleep on it" is one of the most valuable lessons I've ever learned in my professional career. I find that when I start getting tired, my brain starts disk-thrashing for solutions. What I mean is, the time spent in logical analysis plunges and the time spent in trial-and-error, shotgun-style problem solving spikes. In the worst of these sessions - often well after the sun has come back up as I work - I end up with something that looks like a solution, only to reveal its whole host of new bug-inducing behaviors after I run with it and cut a software release or deploy to a production environment. The solution, of course, is to understand this about myself, and know when to put it away for the night, even if the problem isn't solved, and I don't know what the solution is. In fact, it seems that more often than not when I can do this, I wake up to find the problem has a simple solution that I just couldn't see the night before. I don't know what happens while I sleep, and I know it sounds a little silly, ...
Apple: Stop standing in the way of progress
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.
Two Fantastic Uses for AspectJ: Part Two, Bridging
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 ...
Two Fantastic Uses for AspectJ: Part One, Backward Compatibility
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 ...
Now, Which Jar Did I Put That In?
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 ...
