> 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

Reply via email to