How does the module system support Maven’s runtime scope? Ralph
> On Apr 21, 2017, at 10:48 PM, Stephen Colebourne <scolebou...@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.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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
