lundi janv. 10, 2011

Screencast - installing a GlassFish company-internal repository

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

The GlassFish Update Center is a really severely underused feature of the product (IMO). Of course you can install GlassFish and simply ignore the update center and not use it to install updates, 3rd party frameworks, your own packages or upcoming patches but that would be ignoring one of the unique features of the product.

This new screencast shows how to setup a GlassFish Update Center repository behind your company's firewall. It shows access to (which replaced sunsolve) to grab the content of the repository, setting up an internal server (a Publisher), and updating existing GlassFish installs to use it or installing new app servers from this repo.

The offline version is here (75 MB).

The screencast scenario is largely based on this "Extending and Updating GlassFish Server Inside a Closed Network" documentation (for GlassFish 3.0.1) and you may also find "Upgrading to Oracle GlassFish Server From GlassFish Server Open Source Edition" to be useful. Finally, the blog about support from Oracle mentioned at the end of the screencast is here.

vendredi avr. 30, 2010

Staying up-to-speed with GlassFish 3.0.1 developments

With the GlassFish roadmap for the Open Source Edition published and development going full swing for its 3.0.1 release, you may be interested to track development progress as it happens (lots of bugs being fixed). In the case of this blog entry, "as it happens" means following the "promoted" builds which have gone through more testing than the nightly builds and certainly more than the continuous integration builds. Of course you can also build from source.

GlassFish Open Source Edition promoted builds are available from and pushed out every week or so. You can get the latest one (3.0.1-b15 as of this writing) and install the web or the full profile version. Once installed, a typical promoted build has everything wired in so that you can easily update to a more recent build using the command-line of the graphical update tool.

IPS (aka pkg(5)) is the GlassFish packaging system used since version 3 that makes updates trivial. Promoted builds come with several pre-configured repositories ("authorities" in IPS terms) including a "" one where promoted versions are posted. Before you can upgrade you need to make this repository the default one with this magic command:

% bin/pkg set-authority -P

This allows for a mere "% pkg image-update" to upgrade your install to the latest promoted bits. The graphical alternative would be to use the updatetool (from the top-level bin/ directory of your GlassFish install) or to click in the notification window (screenshot above).

Here's a log for the upgrade of build 14 (which is what NetBeans 6.9 beta ships with) to the latest promoted build 15 bits (as you can see it takes significantly less than the 70MB full download) :

$ bin/pkg image-update
DOWNLOAD           PKGS       FILES     XFER (MB)
Completed         34/34     203/203     27.3/27.3

PHASE                 ACTIONS
Removal Phase           28/28
Install Phase           26/26
Update Phase          270/270

Here are a few additional notes :
• At any given moment "% pkg list" with show "U" status in the "UFIX" column for available updates.
• Remember you can also browse any IPS repository, for the 3.0.1 promoted builds (the URLs are easily obtained with a "% pkg authority" command).
• If you installed using the ZIP archive, you'll need to install the IPS tools (done automagically on the first invocation of pkg or updatetool).
• If you don't mind moving from a stable version to these recent promoted (an thus unstable by definition) bits, you can even apply the steps above (set as default and update the image) to a final version of GlassFish v3 to have it be upgraded to a development build of 3.0.1.

There is no promoted build for the moment for the 3.1 branch, but the above information should be equally applicable to that release once they do show up (most likely here)

mercredi sept. 02, 2009

Let GlassFish update itself (v3 preview refresh)

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

If you were a little scared to switch your preferred repository from "stable" to "dev" as explained in my previous entry, you now have the ability to simply update your GlassFish v3 Preview installed image as we've just pushed out an update to the GlassFish stable repositories (both for the Java EE SDK and for GlassFish). See Abhijit's announcement . We carried out more tests than for typical promoted releases posted on the "dev" repository to allow people to upgrade their 3-month old GlassFish v3 release.

The new stable version is build 57 and reasons to upgrade include :
• Hudson no longer has deployment issues.
• You get the OSGi declarative services (see Jerome's blog)
• Jersey moved from 1.0 to 1.1
• tons of bugs fixes
• lots more new Java EE 6 features implemented (the exact delta is hard to compute)
• the update tool itself and its CLI have been updated from 2.1 to 2.2

If you're using the SDK you probably have already been offered to upgrade.
If you don't mind using the command-line, it's easy as this single command :
% bin/pkg image-update
DOWNLOAD                                    PKGS       FILES     XFER (MB)
Completed                                  50/50   3392/3392   72.62/72.62 

PHASE                                        ACTIONS
Removal Phase                                131/131 
Install Phase                                474/474 
Update Phase                               3544/3544 
PHASE                                          ITEMS
Reading Existing Index                           9/9 
Indexing Packages                              52/52 

You'll see that the new version for GlassFish is 3.0-57 (build 57) and that the bits are now up-to-date (no 'u' in the UFIX column).
% bin/pkg list
NAME (PUBLISHER)                              VERSION         STATE      UFIX
ant (                   1.7.1-0.6       installed  ----
felix                                         1.8.0-0         installed  ----
glassfish-amx                                 3.0-57.1        installed  ----
glassfish-appclient                           3.0-57          installed  ----
glassfish-branding                            3.0-57          installed  ----
glassfish-branding-gui                        3.0-57          installed  ----
glassfish-cmp                                 3.0-57          installed  ----
glassfish-codegen                             3.0.0-20        installed  ----
glassfish-common                              3.0-57          installed  ----
glassfish-common-full                         3.0-57          installed  ----
glassfish-corba                               3.0.0-20        installed  ----
glassfish-corba-omgapi                        3.0.0-20        installed  ----
glassfish-ejb                                 3.0-57          installed  ----
glassfish-ejb-lite                            3.0-57          installed  ----
glassfish-grizzly                             1.9.15-0        installed  ----
glassfish-gui                                 3.0-57          installed  ----
glassfish-hk2                                 3.0-57          installed  ----
glassfish-jca                                 3.0-57          installed  ----
glassfish-jcdi                                3.0-57          installed  ----
glassfish-jdbc                                3.0-57          installed  ----
glassfish-jdbc-gui                            3.0-57          installed  ----
glassfish-jms                                 3.0-57          installed  ----
glassfish-jpa                                 3.0-57          installed  ----
glassfish-jsf                                 2.0.0-14        installed  ----
glassfish-jta                                 3.0-57          installed  ----
glassfish-jts                                 3.0-57          installed  ----
glassfish-management                          3.0-57          installed  ----
glassfish-nucleus                             3.0-57          installed  ----
glassfish-registration                        3.0-57          installed  ----
glassfish-scripting                           3.0-57          installed  ----
glassfish-web                                 3.0-57          installed  ----
glassfish-web-gui                             3.0-57          installed  ----
javadb                                    installed  ----
javaee-firstcup-tutorial                      2.0.1-4         installed  ----
javaee-javadocs                               3.0-57          installed  ----
javaee-samples-build                          0.9-4           installed  ----
javaee-samples-full                           0.9-4           installed  ----
javaee-samples-web                            0.9-4           installed  ----
javaee-tutorial                               6.0.1-9         installed  ----
jersey                                        1.1.1-1.0       installed  ----
metro                                         2.0-14          installed  ----
mq-bin-sh                                     4.4-11.5        installed  ----
mq-config-gf                                  4.4-11.5        installed  ----
mq-core                                       4.4-11.5        installed  ----
mq-locale                                     4.4-11.5        installed  ----
mq-server                                     4.4-11.5        installed  ----
pkg                                           1.111.3-30.2311 installed  ----
pkg-java                                      1.111-30.2311   installed  ----
python2.4-minimal                    installed  ----
sdk-branding-full                             3.0-57          installed  ----
updatetool                                    2.2.2-30.2311   installed  ----
wxpython2.8-minimal                           2.8.8-30.2311   installed  ----

If you've downloaded GlassFish from, you have not been notified because the preferred authority (IPS repository) has been set to by mistake. To fix this from the command-line:
% bin/pkg set-authority -P

(this assumes that there's already a repository defined. It only sets it as the preferred).

From there you can simply issue a :
% bin/pkg image-update

and you'll be in for a 74MB download to update your existing install as shown above.

To fix the preferred repository issue from the Update Tool (bin/updatetool), simply select the image and chose "File > Image Properties" to select as the preferred repository. You can then select "Available Updates" and do the update from there.

If you want things like the RESTful admin and monitoring, you'll need to be running a more recent build (promoted build 60 and above in this case).

vendredi août 21, 2009

Updating GlassFish v3 Preview to a more recent promoted build

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

GlassFish v3 Preview is build #47(d) and came out right before JavaOne (May 2009). On the way to v3 final, the team is releasing promoted builds every week. We're now down to build 60, so you can imagine how much has changed and what you're missing out on if you're still on build 47. of course you can download the promoted build and re-install GlassFish, but this entry is all about using the IPS package management tools that ship with GlassFish v3 (in the top-level glassfish bin/ directory) to upgrade an existing install.

If you don't mind living on the bleeding edge (promoted builds are less stable than the "Preview" release by definition) you can change your default authority (IPS repository) from a one (whose content hasn't changed since May) to a authority which hosts promoted builds :

% pkg set-authority --enable -P -O

This defines a new authority as the preferred (-P) source for GlassFish packages.
Optionally you can also disable the stable authority :

% pkg set-authority --disable

In any case, updating to the latest promoted build is a simple as issuing this command (or using the updatetool UI) :

% pkg image-update

If you were to set back to being the preferred repository, that would not roll you back to build 47d (v3 Preview) but it would stop offering you to update every week to the newly promoted build. Finally, note that you cannot disable a preferred authority and that to list all authorities, including those that are disabled, you'll need to use the "pkg -a publisher" command.

jeudi août 20, 2009

Java EE 6 tutorial and samples straight to your GlassFish v3 install

While the Java EE 6 tutorial and the code samples it offers are still work in progress (expect a few rough edges), it's probably a great source for getting up to speed with this update to the Java EE platform. If you've installed the Preview of the Java EE 6 SDK you've probably been encouraged to download an update to the Java EE 6 tutorial:

If you've been using the GlassFish v3 Preview bits from then you may be wondering what this is all about as there is no "Tutorial" package or update showing up in the GlassFish updatetool. Whether this is a feature or a bug is yet to be decided but this is technically due to different repositories being wired in for the two different downloads (glassfish vs. SDK). You can check what your repository settings are with to following command (you can visit the URL for an HTML representation of the contents of the repository) :

% pkg authority
AUTHORITY                           URL                 (preferred)            

If you're using GlassFish promoted builds you have a preferred authority (repository) defined as If you're running GlassFish v3 Preview (released at JavaOne in May 2009), then it comes with a preferred repository defined as

In both cases, in order to be able to see and add the tutorial and sample packages, you simply need to add like this :
% pkg set-authority --enable -O

Once that's done, you can list the tutorial and samples packages available for install and proceed with the install :
% pkg list -a | grep javaee
javaee-firstcup-tutorial ( 2.0.1-4         known ----
javaee-javadocs (          3.0-47.2        known ----
javaee-samples-build (     0.9-2           known ----
javaee-samples-full (      0.9-2           known ----
javaee-samples-web (       0.9-2           known ----
javaee-tutorial (          6.0.1-9         known ----
% pkg install javaee-firstcup-tutorial javaee-javadocs javaee-samples-build javaee-samples-full javaee-samples-web javaee-tutorial

This will install 17MB worth of samples and tutorial documentation and place this all in your glassfish/samples and glassfish/docs directories.

if you're running GlassFish v3 Preview (which already comes a stable repository) it is important that you then either disable or remove the authority. Failing to do so will cause multiple packages conflict on the next update of GlassFish. Here's how to disable the repository:
% pkg set-authority --disable

Of course you can use the bin/updatetool to accomplish all of the above if you're CLI-averse.

mercredi juin 24, 2009

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.

vendredi juin 19, 2009

GlassFish v3 a la carte screencast - Part 3 - Jersey and EJBs

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

In the first screencast, I installed a minimal GlassFish v3 from a small bootstrap (IPS toolkit), created a domain and started the server. The second entry did something actually useful with GlassFish and two containers: Java Web and Spring. In this screencast, I layer a custom distribution on top of a GlassFish kernel. Enough to deploy a JAXR-RS / EJB 3.1 (lite) application.

For the sake of brevity this screencast is mostly command-line. It starts with the 5MB ips bootstrap and installs a pre-defined custom distribution which is enough to deploy the jersey-ejb sample application. The custom distribution is essentially an IPS package with no artifact, only a set of dependencies on other packages. For the curious out there, here is the step-by-step for the screencast :

bin/pkg set-publisher -P --enable -O
bin/pkg set-publisher --enable -O http://localhost:10001 localRepo
bin/pkg install sample-distro
bin/asadmin create-domain --instanceport 8080 --adminport 4848 mydomain
bin/asadmin start-domain
bin/asadmin deploy ~/jersey/jersey/samples/jersey-ejb/target/jersey-ejb.war
open http://localhost:8080/jersey-ejb/

I hope this series of screencasts demystifies the IPS/packaging side of GlassFish and shows the interesting possibilities it offers to end-users.

vendredi juin 12, 2009

GlassFish v3 a la carte screencast - Part 2

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

In the first screencast, I installed a minimal GlassFish v3 from a small bootstrap (IPS toolkit), created a domain and started the server. This entry will actually do something useful with GlassFish and two containers: Java Web and Spring.

The Spring DM (OSGi) part of the demo is described in Jerome's GlassFish V3 Extensions, part 3 : Spring, Java EE 6 and OSGi blog entry. In the screencast, the manual install of the Spring bits is replaced by adding a new repository definition (a local one) and installing a single package from there. For the rest, the demo demonstrates how to extend GlassFish without using any GlassFish API and how to invoke an OSGi bundle service without using any OSGi API - the servlet injects the service by name using a standard @Resource annotation. Note that Jerome's most recent blog entry covers OSGi Declarative Services for a somewhat simpler approach.

The screencast was done using the dev/ repository, so your experience may vary as the boundaries of the IPS packages and their dependencies are still being worked. Also, instead of the default Felix console briefly shown, you could use the web console described by Sahoo.

The full-size (and offline) video is available here (15MB, video/x-m4v).
The next screencast will show how one can seamlessly add more GlassFish v3 features to obtain a "full" Java EE application server and still benefit from the modular architecture in terms of pay-as-you-grow (startup time, load-on-demand, memory consumption, ...).

jeudi juin 11, 2009

How many bytes does it take to update a full GlassFish install?

The answer is 24MB.
... and that's for an initial full install weighting 63MB. The reason for it being small (other than the fact that you \*can\* do such a full update) is that IPS, the packaging system behind GlassFish v3 works at the file level rather than with package granularity.

Your mileage may vary depending on the jump you're trying to make (in my case this was from b47 to b49).
Here's a quick replay of my experience :
% bin/pkg set-authority -P -O --enable
% bin/pkg image-update
Completed 32/32 198/198 24.10/24.10

Removal Phase 64/64
Install Phase 39/39
Update Phase 193/193
Reading Existing Index 9/9
Indexing Packages 41/41

Voilà !

mercredi juin 10, 2009

GlassFish v3 a la carte screencast - Part 1

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

Given the modular approach taken in GlassFish v3 (170+ OSGi bundles in v3 Preview) and the IPS/pkg(5) tooling provided, I created a first screencast showing the following :
• install the IPS toolkit image (download), a 5MB bootstrap
• define the repository to get to the GlassFish v3 bits ( in this case)
• install the minimum set of packages required to create and start a domain (using the pkg command-line and the graphical updatetool)

The full-size (and offline) video is available here (15MB, video/x-m4v).
Further screencasts will show how one can add selected features (containers) to deploy specific applications.

Of course you don't have to be fiddling around with the various GlassFish v3 packages and could also be downloading one of two GlassFish v3 Preview distributions: web profile and full Java EE 6. Even then you'll only pay for what you use.

mercredi avr. 22, 2009

Different strategies for building different packages (for GlassFish v3)

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

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 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).

mardi avr. 14, 2009

Sample Hibernate Community Package for GlassFish v3

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

This is the second of a series of entries for people interested in producing packages for GlassFish v3 and hosting them on a live repository. The previous entry is IPS/pkg(5) crash-course for GlassFish v3 community package developers - Part 1. The next entry is here: Different strategies for building different packages (for GlassFish v3).

In this entry, we'll go through the various parts required to make the Hibernate library available to end-users via the GlassFish v3 Update Center. This enables developers to add this library with a single step, thus avoiding various well-known jar/classloader issues. In a team of multiple developers, all can install the library in the same manner. This provisioning/install approach can be extended beyond the simple use of a library, but let's start with something simple (more in other entries).

As introduced in the previous entry the glassfish-repo project is where it all happens. It provides a bootstrapping mechanism to abstract away the low-level details of creating and publishing IPS packages. Looking at the code hosted on glassfish-repo, you'll find a top-level directory called packager/ which has sub-directories, each corresponding to an IPS package for GlassFish v3.

There's a bit of setup described here for the following:
Update Center 2.x toolkit image. This is the cross-platform bootstrap code needed for creating, publishing, installing, and installing IPS packages. Get it from You will need to add pkg/bin and pkg/python2.4-minimal/bin to your PATH
and pkg/python2.4-minimal/lib and pkg/vendor-packages to LD_LIBRARY_PATH. You will not manipulate this toolkit yourself, a Maven plugin will do it for you.
Subversion (to check out the project code). This is not needed if you create your own local directory structure and don't intend to publish back to this glassfish-repo project (although we'd love for you to share as much as you possibly can).
Maven 2.0.9 (everything is built using Maven2 in GlassFish v3 btw).

Key files and directories
There are really three key files and a directory for building an IPS package (this is documented here, so inlining it here for brevity) :
packager/package-name/pom.xml, the Maven config file to describe any dependency used when building the IPS package and the Maven profile/plugin that does all the packaging magic for you.
packager/package-name/build.xml, the ANT script that lays out the files on disk as they should be installed on the target GlassFish instance.
packager/package-name/src/main/resources/ is called the prototype file and it contains the metadata required to build the package (name, version, license, and various attributes). The file format is well-documented here.
packager/package-name/target/stage is the staging area where the above ANT script should layout the files (with proper permissions) required by the IPS package. This is the root of a glassfish v3 install.

Before looking at the Hibernate example, consider studying packager/sample-package and using it as a template for your own packages.

Authoring the Hibernate IPS package example
The Hibernate package artifacts available from the glassfish-repo project has the following interesting content (click on the filenames to see the entire content):

packager/package-name/pom.xml contains the existing Maven profile and plugin definition encapsulating the IPS logic and adds a dependency to the hibernate-ips artifact (version hosted on the Maven2 repository :

packager/package-name/build.xml simply creates the target/stage directory and places the various libraries required by Hibernate into the lib/ directory, thus making the framework available to all the applications deployed in a domain or instance related to the GlassFish install for which users will be installing this package. Check this link for how to best use the "Common Class Loader" and decide where you need to place your jar files. Optionally you can use the <attachArtifact> tag to create an .ipstgz file (also discussed here) to archive the work done by this script.

packager/package-name/src/main/resources/ contains pretty self-explanatory metadata for the IPS package (name, version, summary, description, and classification). In particular this is where you reference the location of the LICENSE.txt file (name and location can be different). dirtrees offers a way to take a subset of what is in the staging area by explicitly listing the directories that should be considered as being part of the IPS package. More documentation on the format of the file can be found here. Most of this is presented to the user when listing or installing the package. There is no dependency specified for this package. If you are not familiar with the Python syntax, I would suggest you look at IDE's (such as NetBeans) offering Python support (color-syntaxing, etc...) to avoid debugging issues late in the build process.

packager/package-name/target/stage contains a single "glassfish" subdirectory that corresponds to the top-level directory in a GlassFish v3 prelude install and all the Hibernate JAR files are placed into the lib/ directory of the appserver install. This translates into having them placed in GLASSFISH_V3_INSTALL/glassfish/lib. Note that you shouldn't assume the presence of any particular domain such as "domain1" (more on that in another post).

Publishing and testing
Building and publishing is really a single-step process with IPS so you need to start a local repository using:
$ pkg.depotd -d ips-toolkit-dir/pkg -p 10000 --rebuild (running on part 10000. Full documentation here.

At that point, you can simply invoke maven from the package directory root (packager/hibernate in our case) with the appropriate repository URL, the path to the python binary, and the "ips" profile name :
$ mvn -Drepo.url=http://localhost:10000 -Dpython=ips-toolkit-dir/pkg/python2.4-minimal/bin/python -P ips

Once the package is successfully packaged, you can use GlassFish's Update Tool (GF_V3_INSTALL/bin/updatetool) or the pkg CLI to :
• add http://localhost:10000 as an additional repository
• test the package

Another post will soon cover how packages can make their way on to the "live" repository.

If you're interested in the maven-makepkgs-plugin logic/magic used build the IPS on your behalf, read the project's main page, and this post by Kohsuke. You'll find out how to build a package with a single src/ file (no ANT) and getting most of it's metadata straight from Maven.

Going further...
Upcoming entries will covers the process to actually publish your packages to the GlassFish repository. This entry covers Different strategies for building different packages (for GlassFish v3). Expect also more entries on building more advanced packages.

lundi avr. 06, 2009

IPS/pkg(5) crash-course for GlassFish v3 community package developers - Part 1

This blog has moved to
Follow the link for the most up-to-date version of this blog entry.

This is the first of a series of entries for people interested in producing packages for GlassFish v3 and hosting them on a live repository. Part 2 describing the Hibernate package is here. Part 3 discussing different strategies for building different packages is there.

GlassFish v3 (starting with the "Prelude" release from last Fall) uses IPS, aka pkg(5), to manage the various bits and pieces (modules or packages) of the application server. IPS stands for Image Packaging System and comes from the OpenSolaris land and gives GlassFish v3 a graphical (bin/updatetool) and CLI (bin/pkg) tools to manage packages, those that come with GlassFish and the ones available from IPS repositories. The new web admin console also integrates an IPS client. These tools let you browse, install, update, and remove packages very similar to Synaptic/apt, Eclipse, or NetBeans (note that this is different from the technology used for the update center in GlassFish v2). This "Getting Started" is a great intro to using the Update Center.

If you're interested in IPS, there's a bunch of resources around IPS and this IPS primer by Kohsuke is one such good resource for a pragmatic view and tools such as makepkgs, and recommandations for testing packages and moving them around. This current blog entry focuses on the GlassFish perspective and in particular for people interested in creating they're own packages to add features or applications to GlassFish. In the case of GlassFish v3 Prelude, existing packages are listed directly on the various repositories:
"% bin/pkg authority" lists registered repositories while "% bin/updatetool" provides an equivalent but graphical view.

There are potentially really different sorts of packages that can be installed via IPS and the GlassFish Update Center: frameworks, Java EE applications, standalone applications, and GlassFish extensions. Future blogs will go into each of those but, in a nutshell, it's all about laying out files on disk and adding some extra metadata to the package itself (name, license, etc...).

IPS is also used throughout the middleware organization at Sun to deliver its software and is the project that defines a portable (not just OpenSolaris) environment and tools to make this happen. In particular, you will most likely need a pre-installed Toolkit Image specific to the platform used for producing the packages (IPS is written in Python and this toolkit contains the pkg binary, a minimal Python 1.4 runtime, and a number of Java APIs).

The first thing you probably need to know is that is the place to start to avoid having to understand the intricacies of IPS. This is where you will be asked to provide :
• your artifacts (the actual files or a Maven dependency expressed in pom.xml)
• license and readme files
• a simple python file containing additional meta-data: version, description, dependencies, and more
• a build.xml ANT script laying out the bits in a staging area

My next entry in this series walks through the existing "hibernate" package available in source format on glassfish-repo and already live in the contrib GlassFish v3 Prelude repository.

mardi juin 03, 2008

GlassFish v2 on OpenSolaris

One of the nice things about the recent OpenSolaris release is the size of the ISO (it fits on a CD). The IPS (Image Packaging System) takes care of adding the additional features such as GlassFish v2 (with a nice use of ZFS to snapshot before/after state of the filesystem).

Installing GlassFish v2 using IPS and the graphical tool (/usr/bin/packagemanager) is quite easy but has a few gotchas:
• proxy - when using an HTTP proxy, you need to export http_proxy=http://host:port and launch gksu /usr/bin/packagemanager from the same shell.
• no domain created - the binary installed doesn't provide a domain (like the traditional domain1) by default. You need to create the /var/appserver/domains directory before you can use asadmin create-domain.
• the version installed is 9.1_01, not the latest 9.1_02 (or 2.0_02 with the GlassFish numbering)

The total download is around 250 MB (includes JDK 6)


This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected


« juillet 2016

No bookmarks in folder


No bookmarks in folder