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
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
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
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/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
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
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
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
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
>
10 matches
Mail list logo