commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@joda.org>
Subject Re: [all] Java 9 module names
Date Mon, 24 Apr 2017 09:55:13 GMT
Sounds like you could use --add-modules to add the module separately
from the command line, or add the module to the application's
module-info rather than the libraries.

In general, I suspect a library module-info.java should depend only on
the other modules it really needs (eg. the API of slf4j), while
something else, such as the application, adds the implementation
module (eg. the SLF4J implementation).

Stephen



On 23 April 2017 at 18:14, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> Yes, I know it doesn't replace Maven, but in this case I have a dependency that is not
required to compile but is required to run. It appears I have to convert my runtime scopes
to compile in order to get the module to compile and build properly.
>
> That sucks.
>
> Sent from my iPhone
>
>> On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
>>
>> I've never used that myself, but  don't see anything similar.
>> Remember though that JPMS isn't trying to replace Maven. It just
>> intends there to be a reliable set of modules when running in the
>> platform.
>> Stephen
>>
>>
>>> On 23 April 2017 at 08:57, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>>> How does the module system support Maven’s runtime scope?
>>>
>>> Ralph
>>>
>>>> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <scolebourne@joda.org>
wrote:
>>>>
>>>> See http://blog.joda.org/2017/04/java-9-modules-jpms-basics.html and
>>>> https://www.slideshare.net/scolebourne/java-se-9-modules-jpms-an-introduction
>>>>
>>>> Basically, you need "requires static" for optional dependencies. The
>>>> exception if for a module where the dependency is an annotation where
>>>> you don't need the annotation to be present at runtime. eg. @NonNull
>>>> from FindBugs
>>>>
>>>> Depending on things that haven't been modularized yet is risky. It is
>>>> allowed however, and its known as "automatic modules". Basically, it
>>>> looks exactly like a normal "requires" clause, its just that you are
>>>> _guessing_ what the module name of the dependency will be!
>>>>
>>>> This is why I started this thread. By saying _now_what the module name
>>>> will be, you greatly reduce the chance of people guessing wrongly.
>>>> Getting everyone to usesuper-package reverse DNS naming helps too.
>>>>
>>>> Stephen
>>>>
>>>>
>>>>> On 22 April 2017 at 02:11, Ralph Goers <ralph.goers@dslextreme.com>
wrote:
>>>>> On to the next question - which I apologize for asking as it may not
apply to Commons.  Log4j has lots of optional components to support lots of third party stuff
(some ASF projects and some not). How do we handle things that haven’t yet been modularized?
Normally I would expect to have requires directives.
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Apr 21, 2017, at 6:04 PM, Ralph Goers <ralph.goers@dslextreme.com>
wrote:
>>>>>>
>>>>>> Thanks for taking a look Stephen. I appreciate the guidance. I will
be sure to submit a PR when I get something going with Log4j 2.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>> On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <scolebourne@joda.org>
wrote:
>>>>>>>
>>>>>>> Some rules:
>>>>>>> - Each module contains a set of packages, each of which must
be
>>>>>>> specified explicitly.
>>>>>>> - Modules depend on other modules, but must not form a cycle
of dependencies.
>>>>>>> - No package can be in two modules
>>>>>>>
>>>>>>> Looking at the Javadoc here -
>>>>>>> https://logging.apache.org/log4j/2.x/javadoc.html - it seems
like each
>>>>>>> jar file has a separate set of packages it contains, with an
obvious
>>>>>>> super-package for each jar file*. Furthermore, the super-packages
of
>>>>>>> the jar files do not clash, so I think you are fine in naming
terms.
>>>>>>> What I can't be sure from the Javadoc is whether there is a cycle
of
>>>>>>> dependencies.
>>>>>>>
>>>>>>> Possible modules:
>>>>>>> - org.apache.logging.log4j
>>>>>>> - org.apache.logging.log4j.core
>>>>>>> - org.apache.logging.log4j.io
>>>>>>> - org.apache.logging.log4j.taglib
>>>>>>> - org.apache.logging.log4j.jcl
>>>>>>> - org.apache.logging.log4j.jul
>>>>>>> - org.apache.logging.log4j.flume.appender
>>>>>>> - org.apache.logging.log4j.jmx.gui
>>>>>>> - org.apache.logging.log4j.web
>>>>>>> - org.apache.logging.log4j.nosql.appender
>>>>>>>
>>>>>>> * the slf4j bridge is problematic, but is being addressed by
changes in slf4j.
>>>>>>> * the logf4 v1 bridge probably can't be modularized
>>>>>>>
>>>>>>> Bernd has addressed the point about the need to export all packages
>>>>>>> individually, allowing the modules above.
>>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>>>>>> On 21 April 2017 at 21:34, Ralph Goers <ralph.goers@dslextreme.com>
wrote:
>>>>>>>> I am having a hard time figuring out how Log4j is going to
be able to support this.  The API itself is in org.apache.logging.log4j and some packages
under that.  All the main implementation is under org.apache.logging.log4j.core.  These obviously
overlap.  Most of our other jars have packages that are in org.apache.logging.log4j.xxx where
xxx matches the jar name.  We aren’t going to change the API to support modules.
>>>>>>>>
>>>>>>>> Is there some reasonable way around this?
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebourne@joda.org>
wrote:
>>>>>>>>>
>>>>>>>>> On 21 April 2017 at 13:59, sebb <sebbaz@gmail.com>
wrote:
>>>>>>>>>> What happens when there is a API break which necessitates
a package name change?
>>>>>>>>>> I assume that the module name will also need to change
to the new super-package.
>>>>>>>>>> e.g.
>>>>>>>>>>
>>>>>>>>>> Commons-Lang4
>>>>>>>>>> -> super-package org.apache.commons.lang4
>>>>>>>>>> -> module org.apache.commons.lang4
>>>>>>>>>
>>>>>>>>> Yes, thats right.
>>>>>>>>>
>>>>>>>>>> AFAICT Commons generally has obvious and unique super-packages
for
>>>>>>>>>> each component.
>>>>>>>>>> This should make it easier than for larger projects
with lots of jars
>>>>>>>>>> and potentially overlapping package names.
>>>>>>>>>>
>>>>>>>>>> However even Commons has some code that uses a different
package structure.
>>>>>>>>>> e.g. NET uses examples as the super-package.
>>>>>>>>>> This includes working examples that are included
in the release.
>>>>>>>>>> I guess that will have to change (which is probably
a good idea anyway).
>>>>>>>>>
>>>>>>>>> Yes, as it stands, [net] would be a bad modular citizen,
because it
>>>>>>>>> exposes the "examples" package, and thus prevents any
other module
>>>>>>>>> from using that package. Just move it to
>>>>>>>>> org.apache.commons.net.examples.
>>>>>>>>>
>>>>>>>>> Stephen
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message