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 <scolebou...@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
