Introduce module descriptors for all modules

[dmlloyd]

This draft PR introduces module descriptors for each submodule. There are several prerequisites to being able to merge this:

• SmallRye Common release including io.smallrye.common.ref and module descriptors (any release after 2.0.0-RC2 should suffice)
• SmallRye Common release including descriptor for io.smallrye.common.net (blocked on a JBoss Logging descriptor)
• JBoss Modules release including a module descriptor (Introduce module-info jboss-modules/jboss-modules#292, Introduce module-info jboss-modules/jboss-modules#293)
• JBoss Logging release including a module descriptor (Provide a module-info file jboss-logging#45)

[ropalka]

What's the main idea / usecase behind this PR @dmlloyd ?

After I built JBoss Modules with this PR included I can see there are
6 'uses' directives defined in generated moule-info.class:

explicitly specified via module-info.yml

• uses java.util.logging.LogManager;
• uses java.util.prefs.PreferencesFactory;
• uses javax.management.MBeanServerBuilder;

added via bytecode inspection

• uses java.lang.SecurityManager;
• uses java.security.Provider;
• uses org.jboss.modules.PreMain;

According to [1] 'uses' directives specify services for which
the module may discover providers via j.u.ServiceLoader.

JBoss Modules API provides these three methods:

• Module.findServices()
• Module.loadService()
• Module.loadServiceDirectly()

These three methods are kind of a 'dynamic' capability to lookup
various services in provided / defined classloaders. However since
ServiceLoader.load() methods are @CallerSensitive these methods will not
work if jboss-modules.jar is put on the module path.
j.u.ServiceLoader calls will fail for services not specified
in generated module-info.class.

[1] https://docs.oracle.com/javase/specs/jls/se9/html/jls-7.html#jls-7.7.3

[dmlloyd]

What's the main idea / usecase behind this PR @dmlloyd ?

It's an incremental step towards being able to have module descriptors for certain core components.

Many more steps are needed before we would be able to boot JBoss Modules off of the JPMS module path. This change only assumes that, once that is complete, some module named org.jboss.modules may be present (note that the dependency is static i.e. optional).

I guess you might have meant to ask this question on jboss-modules/jboss-modules#292 or jboss-modules/jboss-modules#293 though?

[ropalka]

Yes, I mistakenly posted my question here @dmlloyd

[marekkopecky]

Many more steps are needed before we would be able to boot JBoss Modules off of the JPMS module path

@dmlloyd Hello, do you have some jira tracker for this effort?

[dmlloyd]

No, there is no such JIRA.

[marekkopecky]

Some jira tracker would be definitely useful (and probably is required, cc @LittleJohnII, @msve, @darranl). Now it's not clear what is the specific goal, what is the target release, what are the milestones, whether it is enhancement or RFE, whether there is/will be some backward incompatible changes, which projects are affected, etc.

[dmlloyd]

Some jira tracker would be definitely useful (and probably is required, cc @LittleJohnII, @msve, @darranl). Now it's not clear what is the specific goal, what is the target release, what are the milestones, whether it is enhancement or RFE, whether there is/will be some backward incompatible changes, which projects are affected, etc.

I understand what you're saying, but it's not actually planned to do any of this, at least not at the moment (and maybe not ever). Mostly this issue, and the "would-be" modules issue, are spillover from the effects of getting spec implementations to support module descriptors. None of these changes actually require a JPMS-aware JBoss Modules though, at least not at present.

[jamezp]

Replaced by #407