GlassFish v3 (custom) distributions with IPS

In the last part of my ‘GlassFish à la carte’ series of blogs and screencasts there is a missing piece if you were to try to reproduce the scenario – the GlassFish v3 IPS package containing the definition of my custom distribution (a distribution could be thought as a product/implementation of the notion of a profile as defined in Java EE 6).

That custom distro is the set of core GlassFish v3 packages which are required by my application (in this case it was using JAX-RS and EJB 3.1). While most GlassFish packages are meant to contain some sort of artifact (most likely a collection of JAR files as explained in these posts), this “distro” package for GlassFish has no such artifact but rather a key depends section of the package prototype file.

You can find the source for building the package on the glassfish-repo project site. As you can see there, the list of required modules is simply expressed :

"depends" : {
"pkg:/felix@1.8.0" : {"type" : "require"},
"pkg:/glassfish-amx@3.0-51" : {"type" : "require"},
"pkg:/glassfish-common@3.0-51" : {"type" : "require"},
"pkg:/glassfish-corba-omgapi@3.0.0-20" : {"type" : "require"},
"pkg:/glassfish-ejb-lite@3.0-51" : {"type" : "require"},
"pkg:/glassfish-grizzly@1.9.15-0" : {"type" : "require"},
"pkg:/glassfish-hk2@3.0-51" : {"type" : "require"},
"pkg:/glassfish-jca@3.0-51" : {"type" : "require"},
"pkg:/glassfish-jsf@2.0.0-13" : {"type" : "require"},
"pkg:/glassfish-jta@3.0-51" : {"type" : "require"},
"pkg:/glassfish-management@3.0-51" : {"type" : "require"},
"pkg:/glassfish-nucleus@3.0-51" : {"type" : "require"},
"pkg:/glassfish-web@3.0-51" : {"type" : "require"},
"pkg:/jersey@1.1.0-1.0" : {"type" : "require"},

Note that this requires using the repository which hosts the promoted builds of GlassFish v3. With a stable build (once GlassFish v3 is declared final), the explicit implementation could go away (mostly the -51‘s in the example above which refer to promoted build 51). Finally, the glassfish-jca module listed above should really not be required if it wasn’t for a silly bug (that is fixed in the next promoted build).

So there it is, a really simple way to make sure a given set of packages will be present before you deploy your application. Of course the packages that make up a distribution do not need to all be core GlassFish package. In particular one could imagine including the Spring container as demoed here and discussed there.

Maybe we should create two such packages for the two official Web and Full distributions Sun offers for GlassFish v3.

Author: alexismp

Google Developer Relations in Paris.

%d bloggers like this: