GlassFish V3 build and packaging team meeting

June 20, 2008

Here are Kohsuke's build issues, and Ken's notes (the bulleted items) from the discussion in the
meeting. A recording of the meeting is available, and I have ordered a transcript,
which I'll try to clean up and post here after it is available. I'll see about making the audio
available here as well.

Kohsuke's slides are available on this page as an attachment (click on the attachments link on the bottom
of this page).

Maven repository manager

One of the painpoints we have today is the # of Maven repositories that we have to hit for a build. Because Maven doesn't remember which artifacts are in which repositories, it often has to hit several repositories just to get 404. We also suffer slow network bandwidth with some of the remote repositories. The usual solution to this problem is to use a Maven repository, and my recommendation is Nexus. This allows a single repository manager to act as a Maven-aware HTTP proxy to all our upstream Maven repositories. In this way, our builds would only have to hit our Nexus and it should reduce the build time. For this to work, we need one mirror inside firewall and one mirror outside firewall. That means the actual deployment of this would have to wait for the commission of new http://glassfishbuildtools.sun.com/

• Today: 5-6 repositories are used, some of which may be slow or unavailable
• Multiple repos confuses maven instead of providing redundancy
• How big a server is needed?
• Snjezana: we should push on this and escalate it
• Start internal first
  • External: need security (problem with glassfishbuildtools.com server)

Distribution assembly just by Maven

The distribution assembly process has evolved to the point that it can probably do without Ant build script. To make this part of the system easier to understand, it might be a good idea to rewrite this into a pure Maven plugin (or into a Groovy script with GMaven).

• Nice to have, but can defer until after first release

svnmerge and personal builds

Several people has been using svnmerge in the development of the Hudson project successfully, and this seems like a good way to emulate a hierarchical workspace in Subversion. Being able to commit changes to a repository without qualifying it first has a number of benefits, such as offloading QL and integration to Hudson.

• Nice to have, but can defer until after first release

JVM problem in jar handling

We are experiencing an elusive JVM bug, which manifest itself as various form of jar corruption. We've seen it in many places, and this really needs to be tackled.

• Who on JDK side owns this? no one yet:
• Which JDKs? Hudson: platform: Ubuntu solaris. JDK 5 and 6 error, sometimes VM crash: (Harsha suggests Martin Buchholz)
• Harsha: file bug, work with Terena

Public Hudson server

We need to keep pushing the lab guys to set up the new http://glassfishbuildtools.sun.com/ We should also get a better host name alias like http://hudson.glassfish.org/ and http://maven.glassfish.org/ since we should be running multiple things here.

• Ticket filed by Dinesh, cc'd Kohsuke, Abhijit
• Also need more useful virtual host names

Remove cyclic dependencies

Some part of GFv3 builds contain cyclic dependencies in a subtle way. At module level, there's no cycle (or else Maven wouldn't even let us build), but at the build level, there are a cycle between the main GFv3 build and the admin GUI build. This inflicts a number of pains — in particular it makes it impossible to use the maven-release-plugin on GFv3. This needs to be fixed.

• Identify problems: AMX, GlassFish API
• Who should own this issue? Bhakti will look at this.

Regular non-SNAPSHOT releases

We push our artifacts to the Maven repository, and that's good, but most of them are pushed as SNAPSHOTs today (even TP2 was pushed like that), so people outside GF cannot rely on them. We need to start pushing weeklies and milestones in non-SNAPSHOT version numbers. We've never run maven-release-plugin on GFv3 code base as a whole, so this is mainly an exercise to iron out all the kinks in doing so. Another aspect in this problem is the transition of the build from SNAPSHOT dependencies to non-SNAPSHOT dependencies. I've heard from Jerome that he's been making some progress on this front, but this needs a careful design and experiments.

• Important for outside users

GlassFish v3 Builds Today.pdf (application/pdf)