Fixes #142 adding Automatic-Module-Name entry into MANIFEST

[panga]

Fixes #142 adding Automatic-Module-Name entry into MANIFEST using a generated module name from project.artifactId (will work seamlessly for new modules), customizable by module.name property (e.g: hammock.core).

Example module names generated by this patch: hammock.core hammock.bootstrap.weld3 hammock.web.undertow hammock.johnzon hammock.rest.cxf hammock.security.jose hammock.util.metrics hammock.messaging.rabbitmq hammock.jpa.hibernate

[johnament]

Hi @panga just wondering, is it necessary to use the groovy plugin to generate the value? I get that it could be dynamic, but I'm not sure having a large # of modules is a big issue here. Thoughts?

[panga]

@johnament we can't generate maven variables without a plugin (written from scratch) or using some scripting (Groovy, Ant, JS).

The number of modules is not an issue as long as they don't share the same root packages.

[derekm]

@johnament @panga -- The logic for automatic module name generation is going to need to be a little (or a lot?) more complicated than what is provided by this patch. This patch works in naive cases, but it will produce names that fail in more complicated cases.

Maybe someone should write a proper Maven plugin, but the grammar for module names is here:

https://docs.oracle.com/javase/specs/jls/se9/html/jls-7.html#jls-7.7

This naive approach would fail on Scala-like names such as my-scalibrary-2.10 or my-scalibrary-2.12, where module name parts can't begin with number, or with names that contain Java keywords such as some-interface-impl-native or poorly-named-package-v2-final or framework-abstract-impls, etc.

[panga]

@derekm the naive approach should work in most use cases and if a special naming need to be defined, you can just define <module.name>hammock.somemodule</module.name> in pom.xml to override the generated name.

In summary, we shouldn't depend on any plugin to generate module names, IMO they should be explicitly defined. However, time-to-market etc. we need something working now :)

[derekm]

Yeah, true. I was thinking the auto-generating code should validate its inputs & fail with appropriate error messages, but I guess you're also right that people should be specifying module names explicitly instead of relying on auto-generation.

Wasn't trying to hold up the PR so much as provide food for thought. Perhaps this feedback is more appropriate for someone who ventures to write a Maven plugin for this instead of a solution that is highly specific to Hammock!

PS: @panga, I really enjoyed your MicroProfile+JPMS article that used Hammock! Excellent work there and here!

[panga]

Thanks @derekm 🙇

I loved to work with Hammock, it has a great potential! (more than other app servers with microprofile compatibility 😄 )

Regarding the PR, my intention was to move forward and start JPMS support (the first step is to add Automatic-Module-Name). Reference: https://dzone.com/articles/automatic-module-name-calling-all-java-library-maintainers

[johnament]

Right @panga adding automatic module names is on the todo. I was more questioning whether we needed to dynamically name them or if it makes sense to simply use a static value per pom and name it that way. There aren't many modules, so including this shouldn't be a big deal. Thoughts?

Also, on my local it takes 2.5 mins to build hammock without this patch. Does the groovy runtime add any time to the build?

[panga]

@johnament I thought the same initially, but some time later I come to conclusion to automatically add the module based on the project artifact (for consistency) and allow custom module names if required. This will help to not forgot to add module names :)

Regarding the build time overhead, once the jars are downloaded it won't affect the build time.