In my previous two posts (related to building packages for GlassFish), I covered the basics of the Update Center for GlassFish v3 and the underlying IPS/pkg(5) technology and what it takes to build a Hibernate package for GlassFish v3.
One key part that is still missing is the process (or social) side of things - how does one get to commit to the glassfish-repo project, and maybe more importantly, how does a community package make its way to the pkg.glassfish.org/v3prelude/contrib/ repository that is wired into every single GlassFish v3 distribution? This part needs a little more fine tuning and I will cover it soon in a dedicated post. In the mean time, I encourage you to join the glassfish-repo project as a developer.
In this post I'll cover the different possible natures for GlassFish v3 packages beyond the (rather simple) Hibernate example described earlier and available here to study. As you will see the spectrum of packages for GlassFish can be quite large.
1/ Frameworks and libraries
Examples include web frameworks, JDBC drivers, and any other technology that simply requires a set of JAR files to be available from the application running in GlassFish. Such JAR libraries should be placed into GLASSFISH_HOME/glassfish/lib. There is no need to restart GlassFish unless this is a new version of a library with the same JAR file name (individual applications may need to be restarted though). Note it is recommended that you do not touch the default GLASSFISH_HOME/glassfish/domains/domain1 domain. This is because putting any IPS-controlled file in that directory and having GlassFish (or the developer) modify or remove it will show up as a "partially installed" package.
This package use-case is the simple approach discussed in the previous Hibernate use-case.
2/ Applications running in GlassFish
Assuming an application packaged in a WAR, JAR, or EAR has no external resource dependency (connection pool, JMS queue, etc..), the IPS package can simply place the artifact in the autodeploy directory of a domain. As stated above the issue is that there is no guaranty that domain1 exists. One approach is to create IPS packages with a dependency on another IPS package responsible for creating a generic "updatecenter" domain (name TBD) thus installing that package/domain if it's not already there. This would also avoid each application shipping with its own domain causing unnecessary space to be used, additional admin tasks to manage the domains, and potential port conflicts. Notable exceptions would be packages requiring considerable setup of the domain (specific jvm options, data-sources or other resources pre-configured, etc.). In this case, shipping the application with a pre-configured domain actually makes more sense.
With the approach of placing the application in the updatecenter/autodeploy directory, removing the package will delete the archive from the autodeploy directory and thus cause the application to be undeployed. Removing the "updatecenter" package will cause the applications depending on it to be no longer available as the domain directory would be deleted. Ideally the domain needs to be stopped first.
3/ Applications independent of GlassFish
Applications running in a separate process can be installed as top level directories and thus be quite independent from the GlassFish v3 runtime bits. Sample packages include monitoring applications, tools, databases, etc. In this case, laying out files at the root of the target/stage staging area will result in a top level install sitting next to GlassFish, similar to JavaDB in the current GlassFish v3 builds. Such a tool can then reference the glassfish v3 install using ../glassfish. You may also want to add binaries to glassfish/bin referencing your application or tool. In the case of JavaDB, there is even an additional ../glassfish/bin/asadmin command (start-database) and that takes us to the next type of GlassFish packages: extensions to the runtime and admin tools.
4/ GlassFish extensions (HK2/OSGi components)
Being modular in its own right, GlassFish supports placing JAR files under the glassfish/modules directory. Of course the artifacts placed there need to adhere to certain rules fairly well documented in the Add-On Component Development Guide (especially the "Writing HK2 Components" and "Adding Container Capabilities" sections). Note you can also extend the admin console, the CLI, and add monitoring capabilities. All of these tasks are quite orthogonal to the (rather lightweight) effort of producing the actual IP package placing the artifacts into the GlassFish modules directory (check the above "Frameworks and libraries" section for how to drop files into a specific directory).
A word on (post-)install scripts
As you can see in the discussion above, it's all about laying out files on disk. GlassFish/IPS packages cannot start/stop processes or run scripts during or after time install by default (if you really need pre/post actions, read this and this). Of course you can (and are actually encouraged) to provide instructions in the package description (in the prototype file), a README.txt file that remains on disk after install, and possibly scripts to be manually executed after the install (to pass some asadmin commands) or prior to some uninstall (like stopping a domain). Remember though that factory configs are best (albeit not always possible).
You should note that the above are merely suggestions for how to build packages for GlassFish v3, not quite best practices at this point, so we're more than happy receiving feedback and suggestions! As you can see the spectrum of packages for GlassFish can be quite large.
There should be at least two more part to this series: how to get your package into the public contrib/ repository and a more complex package example requiring a domain (and thus a dependency on another IPS package).
![[RSS 1.0 Feed]](/images/v2/rss_14.gif){kind=small}
![[RSS 2.0 Feed]](/images/v2/rss2_16.gif){kind=small}
![[FOAF Subscriptions]](/images/v2/foaf_20.gif){kind=small}
![[OPML Subscriptions]](/images/v2/opml_21.gif){kind=small}
." Blanka 
GlassFish has had a couple of workshops in California and it's now time to swim to 
Je ne sais pas si Nantes est en Bretagne et si le 
I spent a couple of day in Athens and presented for the first time my "Is my J2EE/JavaEE application portable? Should I care?" presentation to the local Java user group, 
