- No artifact, so no module name required.
- This module will be problematic in its current form should we move to real use of the JPMS.
idp-schemahas resources under a
schemapath, 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.
idp-attribute-resolver-impldoes not have a root package, but two. As well as
net.shibbolethpackages, it also includes a legacy package
edu.internet2.middleware.shibboleth.common.attribute.provider(and two classes:
V2SAMLProfileRequestContext) for backwards compatibility - see
. This module will be named ignoring the legacy package.
Jira 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's actual root (and only) package is
net.shibboleth.idp.consent.context. However, the corresponding
-implmodule'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.
- Note that this omits the
-corepart of the artifact name. Is this an issue?
net.shibboleth.idp.relyingpartyso 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.
- 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.
- R = Named according to the root package convention.
- S = Named as a submodule.