#VersionsInModuleNames

[Peter Levart]

+1

I have been planning to write a similar comment. I understand that the 
main desire is to discourage version numbers to creep into module names, 
but no rule can prevent that entirely. We can only advise against it, 
not police it. If one wants to do it otherwise, let him do it. He'll 
soon realize that it doesn't play well...

Regards, Peter

On 03/15/2017 11:13 AM, Stephen Colebourne 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