Rework module structure and packaging
Description
Environment
blocks
is related to
Activity
Ian Young April 21, 2023 at 4:08 PM
Rework with two artifacts for keylists, and resolving the package split issue, is commit bde2a658904bb644c874d03a544425b7920e3bc3.
Ian Young April 21, 2023 at 11:35 AM
Reopening this to make some more changes in the area of keylists.
Previously, the keylists were included as part of the main artifact. The initial change moved those into a single `mda-keylists-rsa`, which is good in that allowed for RSA vs. (in the future) potentially other key types in separate artifacts. However, the keylist resources are in `net/shibboleth/metadata/validate/x509`, which is where the classes in the main artifact also live. This is a bad idea because it's implicitly a split package.
So, we should move the resources into a new package so that there's no package split across artifacts. This will make us compatible with the Java module system and with JAR sealing.
I'm also inclined to elaborate this a bit more by putting the 512-bit and 1024-bit keylists, which I doubt are used in anger these days, into a different artifact again, say `mda-keylists-rsa-legacy`.
So:
Artifact `mda-keylists-rsa` using package `net.shibboleth.metadata.keylists.rsa`
Artifact `mda-keylists-rsa-legacy` using package `net.shibboleth.metadata.keylists.rsa.legacy`.
I think it's also worth considering moving the tests back into the main `mda-framework` module, unless they are genuinely specific to the individual resources.
Ian Young December 6, 2021 at 10:52 PM
I do not want to add more stuff into the MDA artifact names.
Please take the other discussion, which is not about the MDA, to a new issue created for the purpose.
Tom Zeller December 6, 2021 at 10:07 PM
Wrong issue, but what about java-support and spring-extensions ?
Could we prefix those with shibboleth- or something else ?
(I think the java- and spring- prefixes can be confusing when looking at artifacts in WEB-INF/lib)
Scott Cantor December 6, 2021 at 9:50 PM
I’m not a fan of duplicating terms in the group IDs and artifact IDs in Maven, so I’d rather use shibboleth in the group ID (which we do) and not in the artifacts.
I'd like to take advantage of the 0.10 stabilisation release to rationalise some of the stranger parts of the module and packaging structure in the `java-metadata-aggregator` project:
I'd like to give serious thought to changing the artifact name prefix from `aggregator-` to `mda-`. This would put the modules more in line with the naming of things like the IdP.
Note that this would imply changing the Maven `artifactId` for each artifact as well. I don't think this is a big issue given that 0.10/1.0 are going to be breaking change releases.
If we're able to change the module names, I'd like to rename the "pipeline" module to "framework". This would actually make sense instead of being a reference to one part of what's in the product.
There's a separate issue filed for the "blacklist" name. That module can be renamed at the same time; it's less of an issue because it didn't exist as a separate artefact in 0.9.x. I'm thinking `mda-keylists`.
I'd like to change the module `name` fields to something less egregious. It's currently, e.g., "Shibboleth Metadata Aggregator :: Processing Pipeline". We could shorten "Metadata Aggregator" to "MDA" to be more like the way the IdP does it, but I'd like to see what best practice is. I don't think this field is really visible outside the build process and maybe the site.
More functionally, for historical reasons the `aggregator-cli` module end up generating the `aggregator-cli` (perhaps now `mda-cli`) artifact and also the distribution `.zip`. The project had a "distribution" module at one point, but it was unused and later removed. I'd like to reinstate the separate distribution module so that the CLI module is just building the relevant artifact, with the bundling (and subsequent dependency verification) being part of a separate `mda-distribution` module.
I think it would make a lot of sense to do what the IdP does, and generate both `.zip` and `.tar.gz` distributions. This is more about the (un-)packaging mechanism than the contents, although there are some text files in there.
The distribution artifacts should probably change name accordingly, again as seen in the IdP.