The screencast below brings up many different approaches of modularity systems in Java. Hmmm. I never even considered anything beyond OSGi.

• OSGi
• JSR 277
• JSR 294
• NetBeans Modules
• Maven
• SMS
• Jigsaw

Jaroslave Tulach, the guy who wrote the netbeans module system is interviewed here, it's a great discussion.

I'm a big Groovy enthusiast, but I only use it myself for build/deploy scripts.

A real pro demonstrated Groovy's power last night:

Paul Woods ran us through 90 minutes of groovy features last night, and demonstrated how powerful the language can be in the hands of someone who works with it exclusively every day for a year.

I used to be a really fast java programmer. If you wanted something written quickly, I was your guy. But that was "so last month...".

Certainly not today.

And it's a psychological struggle, because I'm fighting back the shame constantly. It's embarrassing as hell being this slow - even when no-one is watching.

Why so slow?

I'm working on my own software now. This is my nickel. Not billing others for my time, so I can do things right.

Such as but not limited to these "better" practices that I used to largely ignore in the interest of speed.

• Writing tests for everything I write.
• Setting up infrastructure first, not a year after I needed it.
• Never writing a similar project twice, using an archetype template and writing a replication routine etc.
• Using Spring dependency injection in each appropriate circumstance instead of when it is convenient.
• Using modularity to organize code into little, discrete, independent jars.
• Using OSGI to keep all my modules clean.
• Interfaces instead of concrete classes for calls between projects.
• Writing a maven generated "site" for each module, that gives a future module developer insight into what's what.
• etc. etc.

Onboarding looks pretty jacked up!

Speaking of jacked, I highjacked the video to make my blog look better, but I'd recommend going to the Sonatype blog. This is sharp stuff. 

If you know the guys at Sonatype - I know Jason anyway, and to me seems every bit as fruity oddball as myself or any of us - but just this one time - I'm accusing him of really hitting the freaking nail on the head.

There's a couple things I'd like to point out that make this an insanely smart announcement.

Summary:

"We get it" was the three word version of this presentation. Rod Johnson, the creator of Spring should be proud that the entire focus of JEE and GlassFish teams seems to have been to enthusiastically and shamelessly imitate his every move in recent years. Almost no reference was made to Spring or the driving force behind the latest changes, but it's a credit to the many JSR working groups that they allowed themselves to be so thoroughly influenced by the direction that market moved when Spring supplanted so much of the market that EJBs were intended to serve 10 years ago.

There were over 50 attendees.

To wit - the following technologies were described as "new" that seemed to follow rather than lead, the trends set by market forces years ago.

JavaMUG, our local Dallas area user's group (Java Metroplex User's Group) moved our meeting locations to Cisco this month. With Oracle's purchase of Sun, we had lost our last meeting space that we had for the last 5 or so years. Many thanks to Cisco for pitching in and offering us the fantastic space.

As usual, our invitation to Cisco's facilities arrived on a google map. A big complex, like other Cisco facilities around the world.

We knew we were walking up to the right building though, because the pizza delivery truck was parked outside. Photos below show what you would miss, if you were a local who had somehow not heard about our group.

Compact, Helpful, Well Produced - All in One Place

OSGI isn't just a technology, it's a different way to think, a different kind of design. It can be a real trick to get one's head around. This screencast from SpringSource might help.

Every technology can enable questionable or even destructive uses. What follows is one that OSGI enables.

From that perspective, this screenshot is perfect OSGI anti-pattern. OSGI going to the dark side. (No, it has nothing to do with groovy or the plugin shown)

... from the "Can't We All Just Get Along?" department, you may feel as I do... You want to be lazy where you can, and let these specific Java tools do your work for you. 

• Maven
• OSGI
• SpringOSGI
• m2eclipse

And of course, you want it to happen without them fighting each other, and without keeping multiple layers of duplicate metadata synched up in pom.xml, MANIFEST.MF, and gosh knows what other files. In other words, you want DRY.

Sounds great huh? Consider Tycho, if that's your situation. This is Sonatype's work in progress, which neither supports nor fights Spring OSGI, and lets you use the MANIFEST.MF file as your configuration instead of your pom.xml. Even works with p2, if that's you thing.

So I decided to take it for a spin, even though it isn't supposed to be ready yet.

Finding myself being in the strange position of being a "supporter" or enthusiast for a specific software shop. Mr Anti-Brand goes against pattern?

Well, maybe being a brand enthusiast is an anti-pattern for me personally, but it keeps on making sense for our little shop, regardless. At least in this one situation.