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