Blacklist modules autoloaded via manifests

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Blacklist modules autoloaded via manifests

Ben Weidig

I want to propose a small addition to the IOCUtilities:

It's already implemented, a patch is attached to the ticket. If there are
no objections or change requests, I would like to commit the changes to
master for 5.7.0


Add blacklist for auto-loaded modules via JAR manifests.

Motivation / Goals
Right now, we can specify a list of modules to be auto-loaded with the
property "Tapestry-Module-Classes" in a MANIFEST.MF of a JAR.
This is great from a "batteries included" perspective because we just need
to add a dependency to our project, and it "just works".

Even though Tapestry is immensely flexible, we now have to use the Module
"as provided" with maybe no chance for customization.
This might lead to us forking the dependency and removing the module from
the manifest, to gain back more control.

As discussed earlier on the mailing list, this could mean that any
changes/bugfixes of a forked dependency won't benefit the original.
And of course, we have to maintain our fork.

To mitigate these issues, I suggest the possibility to blacklist modules
loaded from MANIFEST.MF.
The blacklist only affects MANIFEST.MF related modules.
Non-available but blacklisted Modules should be ignored.

Risks and Assumptions
No risk is assumed.

The blacklist is an additional feature, not changing any previous behavior
if not present.

Forking a dependency and removing the module(s) from the manifest.

Details of Proposed Changes
Adding a new system property "tapestry.manifest-modules-blacklist" is CSV
like "tapestry.modules".

All changes are restricted to org.apache.tapestry5.ioc.IOCUtilities.

IOCUtilities.addDefaultModules(...) would load and prepare the blacklist
and passes it on to IOCUtilities.addModulesInManifest(...).