commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [all] Java 9 module names
Date Sat, 22 Apr 2017 01:11:17 GMT
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


Mime
View raw message