#VersionsInModuleNames

[Stephen Colebourne]

Just to complete this thread, see:
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2017-March/000839.html
thanks for the revised proposal.
Stephen



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