[GLASSFISH-16447] Packager build performance improvement Created: 25/Apr/11  Updated: 13/Aug/13  Resolved: 13/Aug/13

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Critical
Reporter: Snjezana Sevo-Zenzerovic Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Packager module build performance has steadily degraded in the course of 3.2 release due to introduction of new transitive maven dependencies. Dependency graph resolution through extended ant maven plugin has significant scalability problems and the most effective way to improve packager build performance is to use the combination of maven dependency plugin and ant resource collections to handle packager dependency graph calculations.

This approach will be implemented as part of 3.2 release cycle.

Comment by Nazrul [ 10/Dec/12 ]

This is an important but nice to have feature for GlassFish build infrastructure. We may work on this after all core infrastructure is in place.

Comment by Romain Grécourt [ 07/Feb/13 ]

We've identified 5 steps to improve the build performance:

  1. force the usage of the local uc-toolkit instead of bootstraping pkg for each execution (very slow and unreliable)
  2. run GPG and javadoc only for maven releases
  3. install packages once, reuse IPS images, pack only the installer images
  4. better isolation of plugin execution in the maven build, using a custom packaging type "glassfish-jar"
  5. enable parrallel build (e.g. mvn -T4 install)

  • 1, 2 and 3 were implemented in order to improve the release build (IPS).
  • 4 is partially implemented: the lifecycle execution associated with "glassfish-jar" needs to be defined in the glassfishbuild-maven-plugin and GlassFish poms need to be updated.
  • 5 requires releasing all the custom maven plugin that are not marked as thread-safe
Comment by Romain Grécourt [ 13/Aug/13 ]

Marking as resolved as all items but #5 were implemented.
It is very unlikely that we enable parrallel build someday.

What may happen next is the design of compact tool for dealing with packages, instead of having complex pom logic.
This tool should be generic enough to be possibly reused for building other kind of packages.

Generated at Fri Mar 06 09:16:50 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.