Ten years of "the desktop is dead, web-apps are the only way" makes a great corporate religion. If you're a true believer in this religion, read no further - I'm a non-believer. Requiring a web app should never mean I don't want a desktop - even more.

I want web apps and mobile web apps, sure. But I want the default as a desktop app that can shuffle as much of the computing to the local CPU as is reasonable.

And of course, I want to write the app one time. The platform should be super powerful and fully developed by others. It should update automagically, have superb installers, and a  phenomenal list of features, yada yada. An impossible dream.

If I'm going to break up with my main squeeze: Eclipse - the Platform, especially after I publicly admitted I was seeing another platform, the least I could do is give our relationship an honorable recap. I already vented my long term gripes yesterday.

Yesterday I hinted at how far back my loyalty to the Eclipse Platform goes, as if I was really gun-ho on this relationship. I glossed over warts that bugged me, because I'm a loyal guy.

The truth is, I'm not so excited about this relationship. Not most of the time.

The problem with Eclipse as a Platform is exactly what you would expect from a super powerful, super flexible, open source platform. It is frightfully challenging to maintain a working relationship with, for a small enterprise like my own.

Woohoo! I'm in love!  What a great feeling, to find such a sweet platform that does almost everything I need, and most of it very well.

Sweet! I didn't know 

My main squeeze, Eclipse didn't know I was checking out other fish in the sea, but really I wasn't. I was just googling for "Swing OSGi" and here comes NetBeans releases an OSGi version. 

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.

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.

The first thing you need, if you're going to do enterprise OSGI, is a starting template for a modular project.

5 minutes, right? We've all done this before. Right click in the IDE > new > project > yada yada

Not So Fast

True, that will do the trick in a non-OSGI world. But then there's all the other stuff like

Setting aside my natural state as the reclusive nerd-type I flew in to Silicon Valley this week for my first EclipseCon. Lots of new experiences to take in, new aquaintances, and a first convention representing my new employer, Genuitec.