...
- 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-schema
has resources under aschema
path, which is to say as far as Java is concerned in a package calledschema
. 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-impl
does not have a root package, but two. As well asnet.shibboleth
packages, it also includes a legacy packageedu.internet2.middleware.shibboleth.common.attribute.provider
(and two classes:BasicAttribute
andV2SAMLProfileRequestContext
) for backwards compatibility - see
. This module will be named ignoring the legacy package.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'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 undernet.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
-core
part of the artifact name. Is this an issue? idp-profile-api
also includesnet.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.- 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.
...