users@glassfish.java.net

Re: Glassfish, OSGi and Eclipse

From: <glassfish_at_javadesktop.org>
Date: Mon, 13 Sep 2010 06:55:00 PDT

My existing setup roughly looks like this:

- Pure OSGi, everything is a bundle, including all third-party dependencies.

- There is a pool of 20-50 bundles developed for my project. The project has a number of different applications (datagrinding backend, visual front end, test runners, ...), each corresponding to a subset of the bundle pool.

- There is another pool of ~200 third-party bundles forming the Target Platform (= Eclipse terminology for compile time and runtime dependencies of your workspace projects which are not part of your workspace).

- My Eclipse workspace contains all my application bundles, each as a separate Eclipse Plug-in Project; the target platform for this workspace contains all third-party platform bundles. For each application in my project, there is an OSGi launch configuration, which is basically a shopping list of all workspace and target bundles required for the given application. By clicking on the appropriate launcher, I can run or debug any of my applications instantly, without any packaging or deployment.

This is all you need for working on the project in Eclipse. Build automation is a different story:

- My preferred build tool is Maven. The Eclipse default is PDE Batch tools, where you use Ant to launch a headless Eclipse to run another Ant with additional Eclipse tasks, which is indeed as ugly as it sounds (I'm waiting for Tycho to provide relief.)

- I'm using Maven to assemble most of my target platform. Ideally, I just pull in a ready-to-go osgified dependency from a public Maven repository (usually the SpringSource Enterprise Bundle Repository). When a dependency is only available as a plain old JAR, I use the maven-bundle-plugin to create a new artifact with the required OSGi manifest.

- The second half of the target platform assembly is a PDE batch step to add some required Eclipse bundles to the target platform. This would not be required if Eclipse published their artifacts in a Maven repository.

- The final step, building the application(s) on top of the target platform, is again a PDE batch build.

- These build steps run as a cascade of Hudson jobs, so most of the underlying mess is hidden from the developers' view.

I'm not sure if an OBR would help to simplify this process, as long as people continue delivering non-OSGi artifacts over all sorts of different channels.

Moreover, there is a fundamental mismatch between the OSGi and Maven ways of handling dependencies. OSGi is focused on runtime, and lets you specify a package dependency, leaving some degree of freedom for the artifact (i.e. bundle) to be used for satisfying the dependency. Maven is focused on build time, and for a repeatable build process, you want to nail down the exact versions of all artifacts, while not caring so much about the packages or services they provide.

In short, I don't have a particular expectation about how to work with OSGi, Eclipse and Glassfish, other than this: as simple and as flexible as possible... I think it is too early to file an RFE, there are just too many possible approaches, but I hope some further discussion in this thread will help clarifying the picture.

Sahoo, I read your blog post about embedding Glassfish in an existing OSGi runtime: http://weblogs.java.net/blog/ss141213/archive/2010/02/14/how-embed-glassfish-existing-osgi-runtime

I think that might be a starting point for a solution based just on Eclipse PDE (the IDE part, not the batch tools): put all Glassfish bundles and any third-party dependencies in your target platform, create plug-in projects for your own bundles in your workspace, and use an OSGi launcher to launch the whole lot.

No need for the Eclipse Glassfish plug-in in this scenario: you just (re)start your OSGi framework which happens to contain both Glassfish and your application bundles; you don't (re)deploy your application into a running Glassfish instance. (Often enough, redeploying is not faster than restarting anyway.)

Of course, this would only work for 100 % OSGi applications and not for a combination of a plain old WAR with a couple of OSGi bundles.

Best regards,
Harald
[Message sent by forum member 'hwellmann']

http://forums.java.net/jive/thread.jspa?messageID=482523