You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2018/03/08 17:58:10 UTC
Re: Prepare commons RDF to JDK 9
On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
> <gi...@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 <gi...@harfang.homelinux.org>
>>>> wrote:
>>>> > Would it be useful (and interesting as part of GSoC work) to
>>>> > establish
>>>> > (1) which tools requires fixing,
>>>> > (2) prepare enhancement requests for the respective projects,
>>>> > and in the meantime, adapt the "Commons" build (with a "JDK 9"
>>>> > profile)
>>>> > (3) to disable plugins that do not work yet,
>>>> > (4) provide the option to generate a "multi-release" JAR
>>>> (although
>>>> > it would not be the deployed as part of the official release
>>>> > process)?
>>>>
>>>> Hi, this is Adam Soroka (prospective mentor for this project). I'm
>>>> sorry
>>>> to have been absent from this conversation so far (been very busy
>>>> this
>>>> week) but Gilles has said much of what I would have said, so
>>>> thanks
>>>> Gilles!
>>>>
>>>> I would emphasize a couple of points:
>>>>
>>>> This is a GSoC project. The expectations and the marks of success
>>>> are
>>>> fundamentally different than for many other contributions.
>>>>
>>>> Gilles has rightly pointed out that this is about Commons RDF and
>>>> that is
>>>> all. Kamila unfortunately didn't make that clear in the subject
>>>> line of
>>>> the
>>>> thread, but that was just a slip of the keyboard. It's not about
>>>> any
>>>> other
>>>> piece of Commons. It won't affect them, so there's no need to
>>>> worry about
>>>> how release artifacts or other products for other components might
>>>> be
>>>> affected. They won't be.
>>>>
>>>> I don't think anyone would claim (or has claimed) that Commons (or
>>>> any
>>>> Commons component) should target Java9. The idea here is to work
>>>> with the
>>>> JPMS. There is no obvious or sensible way to do that without using
>>>> Java9.
>>>>
>>>> The tasks that Kamila and Gilles have talked about are (IMHO)
>>>> sensible
>>>> and
>>>> useful. We can discuss how soon and in what way Commons as a whole
>>>> should
>>>> engage with JPMS, but I don't see why that should stop individual
>>>> components from exploring it. In fact, as Gilles points out, that
>>>> will
>>>> be a
>>>> useful way of gathering info for a larger set of efforts.
>>>>
>>>> Lastly, on the assumption that Kamila's work involves a lot of
>>>> "well,
>>>> plugin X doesn't work, so I'll have to talk to that project", we
>>>> are
>>>> doing
>>>> good. That is _EXACTLY_ what should happen during a GSoC project.
>>>> The
>>>> student should be discovering that working on open source software
>>>> is
>>>> often
>>>> (I would say _very_ often) just as much about understanding how
>>>> different
>>>> software projects and communities relate to each other and how to
>>>> get
>>>> efforts synchronized than about just banging out line after line
>>>> of code
>>>> in
>>>> isolation, only to throw the results over a fence to a single
>>>> project.
>>>>
>>>> In summary-- this proposed project shouldn't affect anything or
>>>> -one
>>>> outside of the user base of Commons RDF (which hasn't even reached
>>>> 1.0),
>>>> and it may only result in a lot of documentation and "speculative"
>>>> work,
>>>> and that would be fine, as long as Kamila learns a lot about
>>>> working with
>>>> open source software efforts, which I'm confident she can and
>>>> will.
>>>>
>>>> Adam Soroka ; ajs6f@apache.org
>>>>
>>>
>>>
>>> That's all quite nice but the hard reality is that the tool chains
>>> out
>>> there are simply not ready for JPMS, as I've painfully learned
>>> contributing
>>> to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins
>>> and
>>> tools left and right.
>>>
>>
>> OK but, assuming JDK 9+, there must a way to create artefacts by
>> avoiding everything that breaks (hence the "profile" which all
>> components could use).
>> The end result would be a module whose access rights are enforced.
>>
>> So I do not see MR-jars as a viable options for any
>>> Commons Components at this time. The best we can do ATM is play
>>> with
>>> automatic module names in manifest files
>>>
>>
>> As I've wondered many times here: How do you ensure anything
>> by only writing this in the manifest?
>>
>> and look at what jdeps say about a
>>> 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.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
That seems like a good pragmatic way about it.
Gary
On Thu, Mar 8, 2018, 16:08 Gilles <gi...@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 <gi...@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
> >>> <gi...@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
> >>>>> <gi...@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
> >>>>>>> <gi...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Prepare commons RDF to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Mar 2018 17:17:40 -0700, Ralph Goers wrote:
>> On Mar 8, 2018, at 4:08 PM, Gilles <gi...@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 <gi...@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
>>>>> <gi...@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
>>>>>>> <gi...@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
>>>>>>>>> <gi...@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'm quite sure there is no harm in adding entries.
It doesn't imply that they are correct (cf. recent
issue with the typo in an "OSGi" entry).
What I mean is checking the compilation, using the
"module-path", of an application/other modules that
depend on the automatic modules.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
I almost pooped myself on that one Ralph :-) Good one!
Gary
On Thu, Mar 8, 2018, 17:19 Ralph Goers <ra...@dslextreme.com> wrote:
>
>
> > On Mar 8, 2018, at 5:17 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> >
> >
> >> On Mar 8, 2018, at 4:08 PM, Gilles <gi...@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 <gi...@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 <
> gilles@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 <
> gilles@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 <
> gilles@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
>
>
Re: Prepare commons RDF to JDK 9
Posted by Kamila Molina Orellana <ka...@gmail.com>.
Hi,
Sorry for causing the confusion. I mean to include a general subject since
I think commons would benefit from the results. However, I pointed out in
the content that the work'd be done over commons-rdf. Again, sorry for
that. :D
Regards,
~Kamila.
On Thu, Mar 8, 2018 at 8:23 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> On Fri, 9 Mar 2018 01:47:01 +0100, Bernd Eckenfels wrote:
>
>> Hello,
>>
>> any experience with compiling a JAR with old Java and only adding the
>> module-info.jar with a new class Version? Would that allow to avoid
>> the Need for Multi-Release JARs? (of Course it makes a ugly
>> toolchain).
>>
>
> IIUC, there must be a one-to-one relationship between
> JAR and module; if so, that would seem to forbid your
> scenario.
>
> Regards,
> Gilles
>
> Gruss
>> Bernd
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: Prepare commons RDF to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 9 Mar 2018 01:47:01 +0100, Bernd Eckenfels wrote:
> Hello,
>
> any experience with compiling a JAR with old Java and only adding the
> module-info.jar with a new class Version? Would that allow to avoid
> the Need for Multi-Release JARs? (of Course it makes a ugly
> toolchain).
IIUC, there must be a one-to-one relationship between
JAR and module; if so, that would seem to forbid your
scenario.
Regards,
Gilles
> Gruss
> Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 8, 2018, at 5:47 PM, Bernd Eckenfels <ec...@zusammenkunft.net> wrote:
>
> Hello,
>
> any experience with compiling a JAR with old Java and only adding the module-info.jar with a new class Version? Would that allow to avoid the Need for Multi-Release JARs? (of Course it makes a ugly toolchain).
Log4j 2 has a few classes that take advantage of Java 9 and the log4j-api jar has a module-info.java file in it. We had to create a separate module for those so they could compile with Java 9. We then copy them into the api jar before creating the jar. Yes, you could do that and not place the module-info.class file (or other classes compiled with Java 9) their “normal” locaions but then you would need some special way to detect that the classes are there to be able to take advantage of them.
That all is workable. However, I am pretty sure you could not include such a jar as an OSGi module and there are various other tools that will fail when they encounter the unknown class version.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
any experience with compiling a JAR with old Java and only adding the module-info.jar with a new class Version? Would that allow to avoid the Need for Multi-Release JARs? (of Course it makes a ugly toolchain).
Gruss
Bernd
--
http://bernd.eckenfels.net
Re: Prepare commons RDF to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Mar 2018 17:19:05 -0700, Ralph Goers wrote:
>> On Mar 8, 2018, at 5:17 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>
>>
>>> On Mar 8, 2018, at 4:08 PM, Gilles <gi...@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
>>>>> <gi...@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
>>>>>> <gi...@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
>>>>>>>> <gi...@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
>>>>>>>>>>> <gi...@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.
In the beginning of this thread, I wanted to suggest releasing
two sets of artefacts, one multi-release, and one not.
> I am not serious ;-)
Now I'm disappointed. :-}
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 8, 2018, at 5:17 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On Mar 8, 2018, at 4:08 PM, Gilles <gi...@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 <gi...@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 <gi...@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 <gi...@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 <gi...@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
Re: Prepare commons RDF to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 8, 2018, at 4:08 PM, Gilles <gi...@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 <gi...@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 <gi...@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 <gi...@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 <gi...@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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
>> On Mar 8, 2018, at 11:06 AM, Gilles <gi...@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
>>> <gi...@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
>>>>> <gi...@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
>>>>>>> <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 8, 2018, at 11:06 AM, Gilles <gi...@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 <gi...@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 <gi...@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 <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
> On Thu, Mar 8, 2018 at 10:58 AM, Gilles
> <gi...@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
>>> <gi...@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
>>>>> <gi...@harfang.homelinux.org>
>>>>>
>>>>>> wrote:
>>>>>> > Would it be useful (and interesting as part of GSoC work) to
>>>>>> > establish
>>>>>> > (1) which tools requires fixing,
>>>>>> > (2) prepare enhancement requests for the respective projects,
>>>>>> > and in the meantime, adapt the "Commons" build (with a "JDK 9"
>>>>>> > profile)
>>>>>> > (3) to disable plugins that do not work yet,
>>>>>> > (4) provide the option to generate a "multi-release" JAR
>>>>>> (although
>>>>>> > it would not be the deployed as part of the official
>>>>>> release
>>>>>> > process)?
>>>>>>
>>>>>> Hi, this is Adam Soroka (prospective mentor for this project).
>>>>>> I'm
>>>>>> sorry
>>>>>> to have been absent from this conversation so far (been very
>>>>>> busy this
>>>>>> week) but Gilles has said much of what I would have said, so
>>>>>> thanks
>>>>>> Gilles!
>>>>>>
>>>>>> I would emphasize a couple of points:
>>>>>>
>>>>>> This is a GSoC project. The expectations and the marks of
>>>>>> success are
>>>>>> fundamentally different than for many other contributions.
>>>>>>
>>>>>> Gilles has rightly pointed out that this is about Commons RDF
>>>>>> and that
>>>>>> is
>>>>>> all. Kamila unfortunately didn't make that clear in the subject
>>>>>> line of
>>>>>> the
>>>>>> thread, but that was just a slip of the keyboard. It's not about
>>>>>> any
>>>>>> other
>>>>>> piece of Commons. It won't affect them, so there's no need to
>>>>>> worry
>>>>>> about
>>>>>> how release artifacts or other products for other components
>>>>>> might be
>>>>>> affected. They won't be.
>>>>>>
>>>>>> I don't think anyone would claim (or has claimed) that Commons
>>>>>> (or any
>>>>>> Commons component) should target Java9. The idea here is to work
>>>>>> with
>>>>>> the
>>>>>> JPMS. There is no obvious or sensible way to do that without
>>>>>> using
>>>>>> Java9.
>>>>>>
>>>>>> The tasks that Kamila and Gilles have talked about are (IMHO)
>>>>>> sensible
>>>>>> and
>>>>>> useful. We can discuss how soon and in what way Commons as a
>>>>>> whole
>>>>>> should
>>>>>> engage with JPMS, but I don't see why that should stop
>>>>>> individual
>>>>>> components from exploring it. In fact, as Gilles points out,
>>>>>> that will
>>>>>> be a
>>>>>> useful way of gathering info for a larger set of efforts.
>>>>>>
>>>>>> Lastly, on the assumption that Kamila's work involves a lot of
>>>>>> "well,
>>>>>> plugin X doesn't work, so I'll have to talk to that project", we
>>>>>> are
>>>>>> doing
>>>>>> good. That is _EXACTLY_ what should happen during a GSoC
>>>>>> project. The
>>>>>> student should be discovering that working on open source
>>>>>> software is
>>>>>> often
>>>>>> (I would say _very_ often) just as much about understanding how
>>>>>> different
>>>>>> software projects and communities relate to each other and how
>>>>>> to get
>>>>>> efforts synchronized than about just banging out line after line
>>>>>> of
>>>>>> code
>>>>>> in
>>>>>> isolation, only to throw the results over a fence to a single
>>>>>> project.
>>>>>>
>>>>>> In summary-- this proposed project shouldn't affect anything or
>>>>>> -one
>>>>>> outside of the user base of Commons RDF (which hasn't even
>>>>>> reached
>>>>>> 1.0),
>>>>>> and it may only result in a lot of documentation and
>>>>>> "speculative"
>>>>>> work,
>>>>>> and that would be fine, as long as Kamila learns a lot about
>>>>>> working
>>>>>> with
>>>>>> open source software efforts, which I'm confident she can and
>>>>>> will.
>>>>>>
>>>>>> Adam Soroka ; ajs6f@apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> That's all quite nice but the hard reality is that the tool
>>>>> chains out
>>>>> there are simply not ready for JPMS, as I've painfully learned
>>>>> contributing
>>>>> to Log4j 2. MR Jars, module-infos, all of that breaks Maven
>>>>> plugins and
>>>>> tools left and right.
>>>>>
>>>>>
>>>> OK but, assuming JDK 9+, there must a way to create artefacts by
>>>> avoiding everything that breaks (hence the "profile" which all
>>>> components could use).
>>>> The end result would be a module whose access rights are enforced.
>>>>
>>>> So I do not see MR-jars as a viable options for any
>>>>
>>>>> Commons Components at this time. The best we can do ATM is play
>>>>> with
>>>>> automatic module names in manifest files
>>>>>
>>>>>
>>>> As I've wondered many times here: How do you ensure anything
>>>> by only writing this in the manifest?
>>>>
>>>> and look at what jdeps say about a
>>>>
>>>>> 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.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons RDF to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Mar 8, 2018 at 10:58 AM, Gilles <gi...@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 <gi...@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 <gi...@harfang.homelinux.org>
>>>>
>>>>> wrote:
>>>>> > Would it be useful (and interesting as part of GSoC work) to
>>>>> > establish
>>>>> > (1) which tools requires fixing,
>>>>> > (2) prepare enhancement requests for the respective projects,
>>>>> > and in the meantime, adapt the "Commons" build (with a "JDK 9"
>>>>> > profile)
>>>>> > (3) to disable plugins that do not work yet,
>>>>> > (4) provide the option to generate a "multi-release" JAR (although
>>>>> > it would not be the deployed as part of the official release
>>>>> > process)?
>>>>>
>>>>> Hi, this is Adam Soroka (prospective mentor for this project). I'm
>>>>> sorry
>>>>> to have been absent from this conversation so far (been very busy this
>>>>> week) but Gilles has said much of what I would have said, so thanks
>>>>> Gilles!
>>>>>
>>>>> I would emphasize a couple of points:
>>>>>
>>>>> This is a GSoC project. The expectations and the marks of success are
>>>>> fundamentally different than for many other contributions.
>>>>>
>>>>> Gilles has rightly pointed out that this is about Commons RDF and that
>>>>> is
>>>>> all. Kamila unfortunately didn't make that clear in the subject line of
>>>>> the
>>>>> thread, but that was just a slip of the keyboard. It's not about any
>>>>> other
>>>>> piece of Commons. It won't affect them, so there's no need to worry
>>>>> about
>>>>> how release artifacts or other products for other components might be
>>>>> affected. They won't be.
>>>>>
>>>>> I don't think anyone would claim (or has claimed) that Commons (or any
>>>>> Commons component) should target Java9. The idea here is to work with
>>>>> the
>>>>> JPMS. There is no obvious or sensible way to do that without using
>>>>> Java9.
>>>>>
>>>>> The tasks that Kamila and Gilles have talked about are (IMHO) sensible
>>>>> and
>>>>> useful. We can discuss how soon and in what way Commons as a whole
>>>>> should
>>>>> engage with JPMS, but I don't see why that should stop individual
>>>>> components from exploring it. In fact, as Gilles points out, that will
>>>>> be a
>>>>> useful way of gathering info for a larger set of efforts.
>>>>>
>>>>> Lastly, on the assumption that Kamila's work involves a lot of "well,
>>>>> plugin X doesn't work, so I'll have to talk to that project", we are
>>>>> doing
>>>>> good. That is _EXACTLY_ what should happen during a GSoC project. The
>>>>> student should be discovering that working on open source software is
>>>>> often
>>>>> (I would say _very_ often) just as much about understanding how
>>>>> different
>>>>> software projects and communities relate to each other and how to get
>>>>> efforts synchronized than about just banging out line after line of
>>>>> code
>>>>> in
>>>>> isolation, only to throw the results over a fence to a single project.
>>>>>
>>>>> In summary-- this proposed project shouldn't affect anything or -one
>>>>> outside of the user base of Commons RDF (which hasn't even reached
>>>>> 1.0),
>>>>> and it may only result in a lot of documentation and "speculative"
>>>>> work,
>>>>> and that would be fine, as long as Kamila learns a lot about working
>>>>> with
>>>>> open source software efforts, which I'm confident she can and will.
>>>>>
>>>>> Adam Soroka ; ajs6f@apache.org
>>>>>
>>>>>
>>>>
>>>> That's all quite nice but the hard reality is that the tool chains out
>>>> there are simply not ready for JPMS, as I've painfully learned
>>>> contributing
>>>> to Log4j 2. MR Jars, module-infos, all of that breaks Maven plugins and
>>>> tools left and right.
>>>>
>>>>
>>> OK but, assuming JDK 9+, there must a way to create artefacts by
>>> avoiding everything that breaks (hence the "profile" which all
>>> components could use).
>>> The end result would be a module whose access rights are enforced.
>>>
>>> So I do not see MR-jars as a viable options for any
>>>
>>>> Commons Components at this time. The best we can do ATM is play with
>>>> automatic module names in manifest files
>>>>
>>>>
>>> As I've wondered many times here: How do you ensure anything
>>> by only writing this in the manifest?
>>>
>>> and look at what jdeps say about a
>>>
>>>> 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.
Gary
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>