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
@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 cannot stand.
>>
On Wed, 15 Mar 2017 11:13:25 +0100, Stephen Colebourne
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 ca
On 15/03/2017 19:18, Neil Bartlett wrote:
:
I look forward to reading this. I regard automatic modules as one of the most
dangerous and poorly specified areas of the current spec, and will be taking
this up with the other members of the EG.
The draft specs have detailed the derivation of the
> On 15 Mar 2017, at 18:12, Stephen Colebourne wrote:
>
> 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 say
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 should be
> the one that choo
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)
On 15 March 2017 at 14:34, Alan Bateman wrote:
> 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 Cen
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
automat
pand 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
(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
questi
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
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
In
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
> remain after removing
14 matches
Mail list logo
