Stephen Colebourne scolebourne at joda.org
Fri Mar 24 10:00:54 UTC 2017

Just to complete this thread, see:
thanks for the revised proposal.

On 15 March 2017 at 10:13, Stephen Colebourne <scolebourne at joda.org> wrote:
> Responding to the discussion on the EG list.
> I am now strongly of the opinion that using the language to restrict
> module names to not end in a number is a mistake. The two clear cases
> show two reasons why it is a mistake.
> commons-lang3 is the third version of commons-lang. It was named  this
> way because the API changed, and there was a strong desire to allow
> both commons-lang and commons-lang3 to be on the classpath. Note that
> the package for commons-lang is org.apache.commons.lang and the
> package for commons-lang3 is org.apache.commons.lang3.
> (Again, if we were to name modules after the highest package, it would
> be obvious what the relationship is, and why restricting numbers
> doesn't make sense, because they are allowed in package names)
> fabric8 is a brand name, and an example of the future of naming
> projects. Over time, more and more good project names are being used
> up (just like good user names). Roll forward 10 years, and the chances
> of finding a good project name will decrease. Using a number as part
> of the name is one way to sidestep the problem and expand the number
> of available names.
> If the current #VersionsInModuleNames plan is not changed, the key
> question is What Should These Projects Name Themselves?
> commons-lang-three?
> Maybe, but yuck.
> fabricate?
> Maybe, but really that is a completely different name, and the whole
> point of using the 8 was to avoid using the -ate project name (maybe
> someone else owns "fabricate").
> I'm sure there are plenty of other examples on Maven Central. But it
> doesn't really matter. Both of these are valid reasons to name a
> project with a number at the end. As such, the #VersionsInModuleNames
> proposal cannot stand.
> Since part of the reason for this proposal was automatic modules,
> which have caused problems in other ways, I'll suggest the following
> change to automatic modules. Automatic modules must either contain the
> Module-Name MANIFEST entry, or have a file name that exactly matches
> the desired module name. ie. the standard jar files downloaded from
> Maven Central, eg foo-bar-1.2 must be renamed to be used as an
> automatic module. This means that the proposed rules for removing the
> trailing version and converting dashes to dots would be removed from
> the spec. Build systems and developers are perfactly capable of
> renaming a file - baking specific naming conversion rules into the
> JPMS is inadvisble.
> (Note that the above is not an endorsement of automatic modules in
> general, I believe that there are better solutions to the migration
> problem. But the above is an imporvement to the current state of the
> JPMS.)
> thanks
> Stephen

More information about the jigsaw-dev mailing list