Add blacklist for auto-loaded modules via JAR manifests.
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.
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.
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(...).