Fixes issue#2158 by adding Automatic-Module-Name

[reinhapa]

Adds Automatic-Module-Name to the manifest logic.

The default calculation will take the module name replace all - characters with . and prefixes is with org. in case of the module ehcache-107 a specific automatic module declaration org.ehcache.jcache was added to replace the calculated default name.

[chrisdennis]

The module names are okay (I think)... but the BndConvention probably isn't the right place (congratulations on navigating the build-system though). I'm actually prototyping this atm after your comment on #2158 floated this up to my attention again.

The changes I have staged at the moment put the manifest changes in InternalEhcacheModule and ClusteredEhcacheModule. That's really only the start though - the second issue is getting some test coverage in place to make sure everything is working. I managed to hack that in (could probably do with some cleanup) - but that leaves issues with split packages (right now between ehcache-xml-spi and ehcache-xml). I'm still working on this, but I'll push a draft PR shortly with the changes I have.

[reinhapa]

Would be cool to have those in the next release as I try to migrate the TweetWallFx project to the Java module system and got some other ones that would need this feature too.

[reinhapa]

@chrisdennis Any progress on your prototype so far or would you give me a hint and I could look into it?

[chrisdennis]

This is caught in an awkward place atm. Automatic modules cannot be made to work because the org.ehcache.impl module needs to depend on jdk.unsupported due to its Unsafe usage (modded JDK CHM). A fully modular setup probably the only way we can go. Right now I need to get some time internally to discuss which of the following three approaches we will be taking (in order of likelihood by my judgement):

1. Increment to Ehcache 4.0, drop support for JDK 1.8 (adopt JDK 11 baseline), and have a conventional Java 9 modular setup for the modules, with a non-modular uber-jar. This would also be accompanied by more JDK 11 enabled changes internally (and maybe in API).
2. Use Multi-Release Jars to support modules in the current 3.x line. This is more complex from a build-system approach but does have the least baggage in terms of alignment with other tasks.
3. Declare Java 9 modules "a bad idea" and decide to never implement them.

I'm hoping to get a decision made on this asap... but if I'm right and we go with a major version bump it's not going to happen massively quickly.

[erilor]

@chrisdennis has any decision been made regarding which approach you're aiming for?