Page Comparison

...

1. No artifact, so no module name required.
2. This module will be problematic in its current form should we move to real use of the JPMS. idp-schema has resources under a schema path, which is to say as far as Java is concerned in a package called schema. While this is valid, it's not ideal long term for the usual reasons around uniqueness: only one module may contain a given package, even if the package is not exported.
3. idp-attribute-resolver-impl does not have a root package, but two. As well as net.shibboleth packages, it also includes a legacy package edu.internet2.middleware.shibboleth.common.attribute.provider (and two classes: BasicAttribute and V2SAMLProfileRequestContext) for backwards compatibility - see

   Jira Legacy
   server Shibboleth JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 180d847f-bce4-36b2-9964-771bff586829 key IDP-1457

   . This module will be named ignoring the legacy package.
4. This module's actual root (and only) package is net.shibboleth.idp.consent.context. However, the corresponding -impl module's packages do not lie under this but under net.shibboleth.idp.consent. We therefore use the latter as the implicit root package for the module to provide consistency with other modules.
5. Note that this omits the -core part of the artifact name. Is this an issue?
6. idp-profile-api also includes net.shibboleth.idp.relyingparty so does not have a true root package. We should consider renaming this oddball package or moving it to a new module. Another one to have resolved if possible for V3.4.
7. The JAR is not used on the class path, so doesn't need to be assigned a module name. However, an implementation detail means that we want to assign one anyway, see JPAR-113.
8. R = Named according to the root package convention.
9. S = Named as a submodule.

...