Yes, I know it doesn't replace Maven, but in this case I have a dependency that is not required to compile but is required to run. It appears I have to convert my runtime scopes to compile in order to get the module to compile and build properly.
That sucks. Sent from my iPhone > On Apr 23, 2017, at 7:43 AM, Stephen Colebourne <scolebou...@joda.org> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
