Decide on Java 9 module name(s)

[ljacomet]

With Java 9 now released, we need to reserve module names by using the MANIFEST.MF entry approach - that is having a key Automatic-Module-Name in it.

As a reminder, there are two ways of consuming Ehcache:

• Individual jars, that do not contain any shaded dependencies. The end result is that you have many small jars on the uclasspath.
• Fat jars that contain all of the Ehcache code and shaded dependencies, but not repackaged.

The moment we introduce modularity concepts, even as small as picking a module name, I believe we have to make a choice.
We cannot keep two options in the modular world. As it would mean having different modules containing the same package, which would break any app that would have dependencies which did not pick the same Ehcache distribution.

So I would suggest the following:

Only offer the small jars with module definitions

• that is effectively deprecating our fat jars for the modular world.
• this would solve the shading issue as well, since we would only need dependencies to also have a proper module name and we are good to go.

I would then suggest the following modules (from maven coordinates to module name):

• org.ehcache.modules:ehcache-api -> org.ehcache.api
• org.ehcache.modules:ehcache-core -> org.ehcache.core
• org.ehcache.modules:ehcache-impl -> org.ehcache
• org.ehcache.modules:ehcache-xml -> org.ehcache.xml
• org.ehcache.modules:ehcache-107 -> org.ehcache.jcache
• org.ehcache.modules:ehcache-client -> org.ehcache.clustered.client
• org.ehcache.modules:ehcache-common ->org.ehcache.clustered.common
• org.ehcache.modules:ehcache-management -> org.ehcache.management
• org.ehcache:ehcache-transactions -> org.ehcache.transactions

The following jars would not get a module name:

• org.ehcache:ehcahce as it is a fat jar
• org.ehcache:ehcache-clustered as it is a fat jar
• org.ehcache.modules:ehcache-server as this is not required as long as the Terracotta Server does not run on the module path.

[chrisdennis]

In the current world I think this makes sense... I would however like to then propose we push hard for progress on http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs. Without this implemented there is going to be constant tension when choosing module boundaries between producers and consumers of modules.

[chrisdennis]

Ship has probably sailed on Multi Module JARs... but we should probably "Java modularize" the component modules.

[reinhapa]

@chrisdennis I would like to use ehcache3 as a Java module, but due to the lack of a proper Automatic-Module-Name property I'm not able to properly configure it as the calculated module name leads to a illegal name. Where would be the correct place to add this information in order prepare an according PR?