Open pedrolamarao opened 2 years ago
Hi @pedrolamarao, Is the default module name from the jar not useable in this instance?
Hi @pedrolamarao, Is the default module name from the jar not useable in this instance?
Tools like Gradle will not place a JAR in the module path if that JAR does not contain module metadata.
Forcing the tool is non-trivial.
Defining Automatic-Module-Name
is, on the other hand, trivial.
If there is no objection to this addition, I would gladly provide PRs for all required modules.
@pedrolamarao By any chance, are you able to solve gRPC's module problem already (https://github.com/grpc/grpc-java/issues/3522)? If so, would you share how you setup your project? We'd like to learn how people are using Java modules.
We are currently using a trick where we split every affected module in two, the actual module depending on an "impl" automatic module. We define an Automatic-Module-Name
on "impl" so that tools recognized it as module ready. Then, all classes which contain a reference to Google Cloud stuff goes to "impl". This is incredibly annoying, and is inducing people to give up on architecture and put unrelated things in the same "impl".
Moving to googleapis/google-cloud-java
Is your feature request related to a problem? Please describe. It is currently not possible to create modular applications which depend on
google-cloud-kms
it is not module-ready.Describe the solution you'd like Define an
Automatic-Module-Name
inMANIFEST.MF
to makegoogle-cloud-kms
module-ready.Describe alternatives you've considered The only alternatives are giving up creating modular applications or repackaging
google-cloud-kms
to add the required metadata.Additional context Providing
Automatic-Module-Name
has no impact on non-modular applications or applications targeting Java 8.