> On Mar 8, 2018, at 5:17 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Mar 8, 2018, at 4:08 PM, 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. ;-) > > We have not run into any problems with adding the Automatic-Module-Name > header to the manifest. >
I should have also added that maybe it would be a good idea to make all the Commons jars multi-release. That might generate enough complaints to get Google to fix the issue. I am not serious ;-) Ralph
