Despite all the shit the Java champions talk about OSGi, Jigsaw is still a simplified version of OSGi basically, so anything already supported via OSGi will generally port extremely easily to Java 9 modules.
As for the optional modules, it sounds like static module imports are the way to declare optional modules, though I don't know the details. On 21 April 2017 at 20:11, Ralph Goers <ralph.go...@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.go...@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 <scolebou...@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.go...@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 <scolebou...@joda.org> > wrote: > >>>> > >>>> On 21 April 2017 at 13:59, sebb <seb...@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-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 > >>> > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
