> On Mar 8, 2018, at 11:06 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote: >> On Thu, Mar 8, 2018 at 10:58 AM, Gilles <gil...@harfang.homelinux.org> >> wrote: >> >>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote: >>> >>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <gil...@harfang.homelinux.org> >>>> wrote: >>>> >>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote: >>>>> >>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <aj...@apache.org> wrote: >>>>>> >>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles <gil...@harfang.homelinux.org> >>>>> >>>>>> given component and see if we want to only depend on java.base or create >>>>>> Maven modules to compartmentalize dependencies. >>>>>> >>>>>> >>>>> Then these modules can define "module-info" files, and an actual >>>>> build will prove that the dependencies are as expected. >>>>> >>>>> >>>> As Ralph as pointed out, you cannot generate a module-info file without >>>> also using an MR Jar unless you also want to make Java 9 your base line. >>>> >>> >>> Did you see, a few lines above: "[...] assuming JDK 9+ [...]"? ;-) >>> >>> Related note: Java 9 is the target for compiling >>> "commons-rng-examples" (maven module) >>> in "Commons RNG" because one of the examples is composed of >>> JPMS modules (with "module-info" files) that depend on the >>> "official" artefacts (targeting Java 6) that declare an >>> "automatic module name" in the manifest. >>> >> >> Right now >> https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD >> shows Java 8 as the target. >> >> Are you taking about changing that to Java 9? >> >> I'll that choice to the Common RDF community but it seems that this would >> exclude a lot of users. > > As for "Commons RNG", the purpose may just be to prove (by > usage) that the maven modules are also JPMS modules.
I am so confused. I am not sure what the goal is. Let me put it this way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by introducing a multi-release jar. Android developers can not use any version of Log4j since we did that. What I am saying is that if you turn any jar into a multi-release jar it will no longer be usable in Android and there is no way around it until Android Studio is fixed. The problem is that the android tool inspects every class file in the jar even if it is located under META-INF and it dies if it sees a Java 9 class. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
