Proposal: #AutomaticModuleNames

David M. Lloyd david.lloyd at
Wed Apr 5 00:32:03 UTC 2017

On 04/04/2017 07:08 PM, mark.reinhold at wrote:
> 2017/4/4 5:43:42 -0700, Brian Fox <brianf at>:
>> The Module-Name was enough of a hook to allow us to have Maven "fix" this
>> problem automatically by inserting a name based on the coordinates. Taking
>> that away I think again ties our hands.
> Yes.  That's precisely the point.
> This isn't a "problem" for Maven to "fix".
> The final, explicit name of a module should be chosen by its author.
> It's not appropriate for a build tool or an artifact repository to
> enforce any particular convention for naming modules.

This is deceptive.  Yes, build tools or repositories shouldn't enforce 
conventions for naming.  But at the same time, it's unrealistic to 
expect that module authors are going to bundle module descriptors that 
are universally compatible, and while naming is a part of this, it also 
extends to things like dependency names and export types.  All you need 
is two modules which provide the same specification API in different 
ways to expose this as truth, but the mere existence of Maven's 
dependencyManagement and exclusions also are strong indicators.  OSGi 
can get away with library developers shipping descriptors, sometimes, 
but this is generally a consequence of dependencies being expressed by 
package instead of by bundle name, as well as other key differences 
between the descriptor types.

I think rather what we'll end up with in the end is that non-trivial 
application builders who want to use Jigsaw will rely almost exclusively 
on build tooling to generate or regenerate "real" descriptors "safely" 
for their application distributions, which in turn will be based on 
meta-information from the artifacts being assembled and their build 
descriptions.  The build system has much more capability (and leisure) 
than the run time to analyze the artifact graph to produce a cohesive 
module structure and useful diagnostics.

There are a lot of little reasons why this kind of tooling is really the 
only way users will be able be sure that their assembly of modules is 
internally cohesive and consistent.  The module descriptor is 
fundamentally a different concern from the ABI and behavioral contracts 
of software.  I think that in this light, the entire concept of 
automatic modules is questionable because with such tooling, automatic 
modules give you nothing of value over adding a couple lines of XML to 
your POM.


More information about the jpms-spec-experts mailing list