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.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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
