Re: #VersionsInModuleNames

2017-03-24 Thread Stephen Colebourne
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

Re: #VersionsInModuleNames

2017-03-16 Thread Brian Fox
olebourne < > scolebou...@joda.org> wrote: > > 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 cann

Re: #VersionsInModuleNames

2017-03-15 Thread Stephen Colebourne
On 15 March 2017 at 17:47, Alan Bateman wrote: > This is the consumer choosing a module name for a library that they don't > maintain and renaming that library to match (you are writing the `requires > X` before X exists). All I'm saying is that the library maintainer

Re: #VersionsInModuleNames

2017-03-15 Thread Alan Bateman
On 15/03/2017 17:09, Stephen Colebourne wrote: : The proposal above only applies at runtime, not when authoring. Given a module: module foo { requires bar; } Then the proposal says the requires clause can be satisfied in one of three ways. 1) a real module on the module path named "bar" 2)

Re: #VersionsInModuleNames

2017-03-15 Thread Alan Bateman
On 15/03/2017 10:13, Stephen Colebourne wrote: 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

Re: #VersionsInModuleNames

2017-03-15 Thread Peter Levart
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

#VersionsInModuleNames

2017-03-15 Thread Stephen Colebourne
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

Re: #VersionsInModuleNames too restrictive (cuts of too much)

2016-09-26 Thread Alan Bateman
On 26/09/2016 18:19, Martin Lehmann wrote: Hi all, the new #VersionsInModuleNames seems to be active in JDK9 b136 already. Switching to b136 breaks the build in one of our examples of our Java9 Jigsaw example suite, cf Github: https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw

#VersionsInModuleNames too restrictive (cuts of too much)

2016-09-26 Thread Martin Lehmann
Hi all, the new #VersionsInModuleNames seems to be active in JDK9 b136 already. Switching to b136 breaks the build in one of our examples of our Java9 Jigsaw example suite, cf Github: https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e xample_automatic-module-logging

Re: Proposal: #VersionsInModuleNames

2016-09-12 Thread Stephen Colebourne
On 12 September 2016 at 16:11, Mark Reinhold wrote: > - Revise the automatic-module naming algorithm implemented by `javac` > at compile time and the `ModuleFinder::of` method [2] at run time. > It will now strip any trailing digits and period characters that >