How does GF v3 Build/Development Work?

The GFv3 build works somewhat differently from v2. This page explains the model of how it works in v3, in an attempt to help you understand how to work with Glassfish.

GFv3 consists of multiple "pieces." Each one of them is a maven module. For example, the JAXB runtime used in GF is packaged as a maven module. JavaMail API is packaged as a maven module, so is the admin GUI. Those modules are used in the binary form (in maven jargon, the "artifacts" of the modules) when you compile and run your workspace, so it's important to understand how they circulate.

There are 3 places that maven modules could land.

Java.net repository

The java.net maven repositories (here and here) is a shared repository between all GF developers. The java.net repository always contains binaries for all GFv3 modules and their dependencies. Those binaries are generally expected to be stable, and reasonably frequently updated, but they are not always the latest, since the source code keeps evolving.

Local repository

Another repository is the local maven repository, which resides on ~/.m2/repository. This is your personal repository. Whenever you build or run GF modules, all the dependency jars needed will be picked up from this location. For example, when you run mvn gf:run, all the modules are picked up from here.

Workspace

Then there's a workspace, where your latest change is built. If you have multiple modules checked out, there will be many of those lying around in your system.

No glassfish.home

As you can see above, there's no ${glassfish.home} in GF v3.

Flow of artifacts

java.net⇒local

When maven realizes that it needs an artifact X to perform the requested activity (maybe you are trying to compile module Y that depends on X), it looks for X in your local repository. If X is not present there, maven will download it automatically from the java.net repository. If it exists, Maven occasionally checks the timestamp and see if there's a newer artifact available in the java.net repository. If the java.net repository has a newer version, maven will download it.

Maven can be run with -o to prevent any downloading from the java.net repository. The -U option can be used to force Maven to check updates in the java.net repository.

workspace⇒local

When you build your maven module with mvn install, maven will put the produced artifact into your local repository.

workspace⇒java.net

When you build your maven module with mvn deploy, maven will first put the produced artifact into your local repository, then it also stages files for uploading to the java.net repository. This step is not fully automated yet and still requires some more work.

Putting it all together

With the understanding of how artifacts flow from one place to another, we now know what to answer the following questions.

How do I pick up changes from Joe in xyz module?

Such artifact needs to flow from Joe's workspace to your local repository. So first Joe needs to run mvn deploy to publish the artifact to the java.net repository, then you'll need to run mvn with -U to pick up his artifact.

Alternatively you can check out the xyz module on your local machine and build it by yourself.

How do I work on two modules X and Y at the same time?

Whenever you run mvn install on X or Y, the new binary will be placed in your local repository. So if you make changes in X and you need that change to compile Y, you'd:

1. cd X; mvn install
2. cd Y; mvn install or mvn gf:run

This page (revision-22) was last changed on 15-Aug-09 05:45 AM, -0700 by 62.43.216.18.
This page was created on 26-Mar-07 14:31 PM, -0700 by Kohsuke Kawaguchi.

Back to HowDoesV3BuildWorks