Assembling GlassFish distributions (featuresets, etc)

[OndroMih]

In #25703 I discovered some issues with the content of Embedded distributions and I converted the build to use featuresets, similarly to server distributions, although they are used a bit differently in Embedded distributions. @dmatej approved those changes, with a comment that he’s not in favor of featuresets. So I’d like to discuss this, because I solved some issues with featuresets but I also don’t like how they are used, especially in Server distributions.

As I see it, featuresets in GlassFish are plain Maven artifacts that just depend on other artifacts and serve as a collector/container for dependencies. They group dependencies in logical groups and then dostribution artifacts use them to collect all dependencies and built the distribution artifact. Featuresets can be reused for several distributions, other featuresets can depend on them if they provide a subset of their features.

A summary of issues I found and solved with featuresets:

• I added all MicroProfile dependencies to all distributions with a single featureset. A new MicroProfile featureset groups all MP features and is added to all distributions.
• Embedded distributions didn’t use featuresets and their content was’t synchronized with the content of server distributions. I created featuresets for them, added MicroProfile and Embedded All depends on Embedded Web so that Web is exactly a subset of features in All.

Differences in how featuresets are used:

• in Server distributions, GlassFish build helper plugin is used to process featuresets. It pulls only top-level dependencies, no transitive ones, therefore all dependencies in featurests must be explicitly added to pom
• Embedded treats featuresets as usual Maven dependency and pulls all their transitive dependencies. Featuresets specify dependency exclusions if some transitive dependency shouldn’t be included

I think that featuresets are useful but they should be used as plain dependencies, pulling all transitive dependencies that aren’t excluded. Like now in Embedded, not just direct dependencies like in Server.

Featuresets, as reusable group of artifacts, can be used to specify the relationships between dostributions:

• Server Full is a subset of Server Web (it is now)
• Embedded All is a subset of Embedded Web (it is now after my last PR)
• Embedded All is a subset of Server All, Embedded Web is a subset of Server Web (not ensured right now)

What do you think about this? Do you agree with me to use festuresets with transitive dependencies and exclusions as now in Embedded distributions? Or without transitive dependencies as in Server distros? Or something completely different?

@eclipse-ee4j/ee4j-glassfish-committers

[OndroMih]

One comment - I realized that Server and Embedded distributions are a bit different in how they include dependencies.

Server packages all dependencies as OSGi modules. If they are not already OSGi modules, it transforms them to an OSGi module. Sometimes the resulting module contains its dependencies as embedded (nested) JARs inside the OSGi JAR. Therefore when packaging Server, we don't want to include all the dependencies - these embedded JARs would be included twice in the modules directory, once as standalone JARs which aren't OSGi modules, and second time inside the OSGi module.

Embedded GlassFish takes all JARs and unpacks their contents together, merging all the dependencies into a single runnable JAR. Therefore it needs all the dependencies.

Because of this difference, the current situation makes sense - Server just takes direct dependencies specified in the featurset while Embedded GlassFish takes all transitive dependencies. If Server takes all transitive dependencies as Embedded, as I suggest, it would have to exclude the dependencies embedded in OSGi modules. If we want that Server includes Embedded featureset, I see 2 options:

1. Embedded featureset includes the non-OSGi dependencies directly, Server featureset includes Embedded featureset, excludes those dependencies and adds the OSGi dependency
2. Embedded featureset includes the OSGi dependency, Embedded distributions ignore embedded JARs and only include transitive dependencies, Server featureset includes Embedded featureset and excludes nested dependencies, keeping only the OSGi bundle

The second approach is more closer to what is used currently. Embedded distributions work exactly this way, while Server distributions take only direct dependencies, so don't need to exclude embedded dependencies.