Dev profile to update modules without building the whole GlassFish distribution

[OndroMih]

Note: This depends on a new release of the glassfish-build-maven-plugin with this: eclipse-ee4j/glassfish-build-maven-plugin#204. That's why it's in draft.

This will allow to build a single module and quickly update the GlassFish distribution in appserver/distributions/glassfish/target/stage/glassfish7/glassfish so that GlassFish can be started quickly with the code changes applied.

To apply changes in a specific module that suppots the dev profile:

• stop GlassFish if running
• cd /path/to/module
• mvn -Pdev install
• start GlassFish in appserver/distributions/glassfish/target/stage/glassfish7/glassfish

GlassFish distribution module must be first built by building the GlassFish project as usual.

To add support for the dev profile in other modules:

• in most cases, just set copy.modules.to.distribution.skip property to false (if the module is 3 nested directories below root, i.e. the root directory is at ../../..)
• if the root directory is at a different location, set copy.modules.to.distribution.path.to.root property to the root directory (e.g. copy.modules.to.distribution.path.to.root=../../../..). An example is in the nucleus/admin/rest/rest-service/pom.xml file.
• if the destination file in GlassFish installation is different from modules/${project.build.finalName}.jar, then set copy.modules.to.distribution.destFile to point to the destination file, e.g. copy.modules.to.distribution.destFile=${basedir}/../../..//${glassfish.distribution.dir}/lib/somefileinlib.jar. You can use the ${glassfish.distribution.dir} property which points to the glassfish7/glassfish folder relative to the project root. An example is in the appserver/admingui/core/pom.xml file

[dmatej]

Shouldn't it be already possible just with

mvn clean install -pl :security-ee -amd -Pfastest -T4C

It is quite standard without additional custom magic which we want to avoid in the future.

[OndroMih]

Shouldn't it be already possible just with

mvn clean install -pl :security-ee -amd -Pfastest -T4C

No. With -amd, maven will also build tests and everything that somehow depends on the module, not just GlassFish distribution. I tried it and the build fails on a missing dependency, because some test module dependency isn't built with this command. Even if it's fixed, this command takes 2 minutes on my computer.

With this new dev profile, building, for example, cluster-common module and refreshing it in the GF distribution, takes around 10 seconds:

mvn -T4C clean install -Pfastest -Dcyclonedx.skip=true -pl :cluster-common -Pdev
[INFO] Total time:  8.578 s (Wall Clock)

The fastest I can get with a standard maven build is in 2 steps with:

mvn -T4C clean install -Pfastest -Dcyclonedx.skip=true -pl :cluster-common
[INFO] Total time:  8.718 s (Wall Clock)

mvn -T4C clean install -Pfastest -Dcyclonedx.skip=true -am -pl appserver/distributions/glassfish -rf appserver/featuresets
[INFO] Total time:  01:12 min (Wall Clock)

It still takes around 1 minutes and 20 seconds compared to 10 seconds with the dev profile.

[OndroMih]

I tried to do what I want even without changes in this PR. It's possible but if the path to the file in the GlassFish distirbution is different than usual, it's necessary to provide it manually.

What I did is:

1. Modify settings.xml, set this property: <gfbuild.copyFile.destFile>${basedir}/../../../appserver/distributions/glassfish/target/stage/glassfish7/glassfish/modules/${project.build.finalName}.jar</gfbuild.copyFile.destFile>
2. Add this plugin group: <pluginGroup>org.glassfish.build</pluginGroup>
3. cd into the module project, e.g. cd appserver/admingui/common
4. run: mvn package -Pfastest glassfishbuild:4.0.2-SNAPSHOT:copy-file. It's better to define the property in settings.xml in a profile, e.g. glassfish-dev. Then execute with mvn package glassfishbuild:4.0.2-SNAPSHOT:copy-file -Pfastest,glassfish-dev

If the path is not standard, then I would create a different profile in settings.xml or specify the property on command line.

The benefit of having the configuration in sources is that no separate configuration in settings.xml is needed, and paths for each module are already defined in the repository.