+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
