Avoid references to auto modules. Here's the official advice:

  - Strongly advise developers never to publish, for broad use, explicit
    modules that require automatic modules.  That's risky: An automatic
    module is unreliable, since it can depend on types on the class path,
    and its name and exported packages could change if and when it's
    converted into an explicit module.  It's fine to declare and use
    explicit modules that require automatic modules in limited settings,
    but they should never be published to Maven Central or any similar
    public repository.

Robert

On Sat, 22 Apr 2017 16:25:55 +0200, Bernd Eckenfels <e...@zusammenkunft.net> wrote:

Hm, never had the idea this is needed. I can see that new projects want a pure modules setting, for existing code (using older artifacts) that is less of an requirement. Hm, let's hope people who want modules versions will contribute.

But the hint with automatic modules (file name based) is a good one (as long as they do not require imports?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: jodastep...@gmail.com <jodastep...@gmail.com> on behalf of Stephen Colebourne <scolebou...@joda.org>
Sent: Saturday, April 22, 2017 10:16:40 AM
To: Commons Developers List
Subject: Re: [all] Java 9 module names

On 22 April 2017 at 09:00, Emmanuel Bourg <ebo...@apache.org> wrote:
Le 22/04/2017 à 01:02, Stephen Colebourne a écrit :
I've started a page here:
https://github.com/jodastephen/jpms-module-names/blob/master/README.md
Feel free to raise a PR with more projects at commons or elsewhere in
Apache - I'm just checking the Javadoc and releases to ensure there
are no problems.

Seeing Commons Lang 2 in the list I realize we'll have to dust off the
old branches and publish new releases (lang 2.x, configuration 1.x, jexl
2.x, math 3.x, pool 1.x, etc).

Not necessarily. So long as you specify what the module name would be,
people can in theory use them via the "automatic module" feature. This
may require some changes to maven to map artifacts to modules.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to