That seems like a good pragmatic way about it. Gary
On Thu, Mar 8, 2018, 16:08 Gilles <gil...@harfang.homelinux.org> wrote: > On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote: > >> 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 > > I've asked on this list about leveraging the new features of > JDK 9 in the upcoming release of [RNG]. When it came to > multi-release JAR, I trusted Gary's expedite answer ("Don't > do it") based, as yours, on experience. So, no issue. > > Yet I also wanted to ensure that the maven modules were > JPMS-compliant: Would the declared "Automatic-Module-Name" > behave as expected on JDK 9? > No answer for that one. So I resorted to create a "dummy" > application (see "commons-rng-examples/examples-jpms"). > I guess the same could be done for [RDF] unless there is a > smarter way. ;-) > > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
