You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Kamila Molina Orellana <ka...@gmail.com> on 2018/03/07 03:46:30 UTC
Prepare commons to JDK 9
Dear all,
As an idea for GSoC that came up in [1], we want to settle some guidelines
that other commons projects might follow to make the shift. We came up with
some ideas in [2]. I wanted to ask about some experience you have had while
moving to JDK 9 in other commons-projects.
I wanted to propose this:
1. Make the movement of commons-rdf to JDK 9 generating modules
descriptions automatically through Maven.
2. Generate integration tests to guarantee that modules are working as
expected with JDK 9.
3. Maybe have multi-release JARs?
Since other commons projects follow a similar structure, we can generate
some documentation in a wiki-like media. So, they can make the shit to JPMS
or at least have a guideline. Or I can contribute :D.
Wha do you think?
Regards,
~Kamila.
[1] https://issues.apache.org/jira/browse/COMMONSSITE-103
[2] https://issues.apache.org/jira/browse/COMMONSRDF-75
Re: Prepare commons to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
Hi All:
On a slightly different tack, I think that it is way to early to require
Java 9 for ANY Commons components.
I see a case for updating all components to at least Java 7, and hopefully
8.
What you will likely hear from some quarters are comments of the type "What
feature of Java X is required for a better Commons Y".
Note that from my POV, MR Jars are a catastrophe, breaking tool chains left
and right and I will avoid these like the plague until tools support that
feature through and through, especially Android; as well as the myriad of
Maven plugins that might blow up by looking at class files in the "wrong"
place (META-INF).
The least worst solution is to do the minimum for jars to play in the Java
9 module system, which should not require Java 9 byte codes.
Another item to chew on: There is no LTS plans from Oracle for Java 9 AND
10, in fact the next LTS is for Java 11. So it seems to me then that Java
>=9 and < 11 is a moving target and I would not bend over backward for
anything in that range. Not yet at least.
Gary
On Tue, Mar 6, 2018 at 8:46 PM, Kamila Molina Orellana <
kamila.molina97@gmail.com> wrote:
> Dear all,
>
> As an idea for GSoC that came up in [1], we want to settle some guidelines
> that other commons projects might follow to make the shift. We came up with
> some ideas in [2]. I wanted to ask about some experience you have had while
> moving to JDK 9 in other commons-projects.
>
> I wanted to propose this:
>
> 1. Make the movement of commons-rdf to JDK 9 generating modules
> descriptions automatically through Maven.
> 2. Generate integration tests to guarantee that modules are working as
> expected with JDK 9.
> 3. Maybe have multi-release JARs?
>
> Since other commons projects follow a similar structure, we can generate
> some documentation in a wiki-like media. So, they can make the shit to JPMS
> or at least have a guideline. Or I can contribute :D.
>
> Wha do you think?
>
> Regards,
> ~Kamila.
>
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-103
> [2] https://issues.apache.org/jira/browse/COMMONSRDF-75
>
Re: Prepare commons to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Wed, 7 Mar 2018 09:47:00 +0000, Stephen Colebourne wrote:
> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
> six-month release which is about to be replaced by Java 10, which
> will
> then be replaced by Java 11. Thus, Java 8 is the only sensible
> baseline right now.
Maybe it was incorrectly formulated, but I didn't understand it
that way: Java 9 is *not* to be the default target; the idea is
that the (Commons) artefacts should be usable in an application
that wants to enforce module access rules (the app being based
on JDK 9+, obviously).
> 2) Compiling a single jar file such that it works on Java 8 but has a
> module-info.class for Java 9 using Maven is a right pain in the
> backside. Most maven plugins cannot seamlessly handle it making the
> pom.xml much more complex. Note that you do not need a multi-release
> jar file to make it work. See
> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
So IMO, it's useful that someone does the work that will enable
any Commons component to benefit without going through the pain. ;-)
> 3) It is yet to be demonstrated that JPMS is going to be widely used.
?
> To release a jar file with JPMS module-info.class, it requires that
> ALL dependencies are also JPMS modules with either module-info.class
> or Automatic-Module-Name in the manifest. Most projects are nowhere
> near this position yet.
But most Commons projects are (or should be), since they purports
to be "components" (i.e. bona fide "modules").
> Right now the plan for commons should be simple:
>
> - add Automatic-Module-Name to MANIFEST.mf to lock down the module
> name
I think that most did it already, following your first post about
this.
But it does not *prove* that they are JPMS-compliant. Hence the
usefulness to develop actual tests for asserting it.
For the next release of "Commons RNG", I resorted to move that
proof over to an "example" of usage, but it would certainly be
safer and cleaner to have real, component-agnostic, unit tests.
If feasable, they should probably fit in "Commons Testing" (?).
> - if the project has no dependencies and runs on Java 6 or later,
> consider adding a module-info.java, with the awareness that this is a
> complex task
Is it complex, or is the POM going to grow? If most of the
additions are in the parent POM, it will be mostly transparent
to the individual projects.
Regards,
Gilles
>
> Stephen
>
>
> On 7 March 2018 at 03:46, Kamila Molina Orellana
> <ka...@gmail.com> wrote:
>> Dear all,
>>
>> As an idea for GSoC that came up in [1], we want to settle some
>> guidelines
>> that other commons projects might follow to make the shift. We came
>> up with
>> some ideas in [2]. I wanted to ask about some experience you have
>> had while
>> moving to JDK 9 in other commons-projects.
>>
>> I wanted to propose this:
>>
>> 1. Make the movement of commons-rdf to JDK 9 generating modules
>> descriptions automatically through Maven.
>> 2. Generate integration tests to guarantee that modules are
>> working as
>> expected with JDK 9.
>> 3. Maybe have multi-release JARs?
>>
>> Since other commons projects follow a similar structure, we can
>> generate
>> some documentation in a wiki-like media. So, they can make the shit
>> to JPMS
>> or at least have a guideline. Or I can contribute :D.
>>
>> Wha do you think?
>>
>> Regards,
>> ~Kamila.
>>
>>
>> [1] https://issues.apache.org/jira/browse/COMMONSSITE-103
>> [2] https://issues.apache.org/jira/browse/COMMONSRDF-75
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
Log4j has run into a few of them. The OSGi bind tool has some issues although the latest release fixes some of them. Android’s tools have problems with any jar that contains anything Java 9 related. We have created issues against both of these.
Ralph
> On Mar 8, 2018, at 6:33 AM, Gilles <gi...@harfang.homelinux.org> wrote:
>
> Hello.
>
> On Wed, 7 Mar 2018 22:21:44 +0000, Stephen Colebourne wrote:
>> On 7 March 2018 at 18:56, Ralph Goers <ra...@dslextreme.com> wrote:
>>> Actually, you really do need to use a multi-release jar to include a module-info class file. Otherwise it may be sitting alongside of classes compiled for an earlier java release and various tools will fail because of it.
>>
>> Then those tools need fixing.
>>
>> Using multi-release jar files doesn't really help either, as other
>> tools don't understand those.
>
> 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)?
>
> Regards,
> Gilles
>
>> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
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
>
>
Re: Prepare commons RDF to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
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 Was: Prepare commons to JDK 9
Posted by ajs6f <aj...@apache.org>.
> On Mar 8, 2018, at 12:48 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> 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.
I'm not sure whether we would want to do this in a Maven profile (certainly the other way can work) but if not, we can use a Git branch for the purpose. In any event, there is a difference between working with Java 9 for a GSoC project and moving the component to Java 9.
Again, just to clarify, in no way does this project propose to move the normal (release) baseline for anything at all. (As a side note, I would like to be the first to argue against _ever_ moving it to the non-LTS Java 9, but I think I will have to get in a long line of people who would argue against that! :) )
Adam Soroka ; ajs6f@apache.org
---------------------------------------------------------------------
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 Was: Prepare commons to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
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.
Gary
>
> Best regards,
> Gilles
>
>
> Gary
>>
>>
>
> ---------------------------------------------------------------------
> 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 Was: Prepare commons to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
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.
Best regards,
Gilles
> Gary
>
---------------------------------------------------------------------
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 Was: Prepare commons to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Mar 8, 2018 at 10:21 AM, ajs6f <aj...@apache.org> wrote:
>
> > On Mar 8, 2018, at 12:09 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > 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. 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 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.
> >
> > Gary
> >
>
> "breaks Maven plugins and tools left and right"
>
> Yes. That's the point. That's perfectly fine. Kamila will find out which
> break, and how, and what options we have to deal with them, and when we
> might need to go upstream and come back, and she will document that, and
> she will do what work can be done now on those problems.
>
> If Commons RDF does not release MR JARs as part of the GSoC project, but
> we do understand specifically and in detail why and what the blockers are,
> the project will have been a success. With respect, I think you are now
> objecting to a project that hasn't actually been proposed, for which
> success would be releasing MR JARs. _That is not what is being proposed._
>
Good! :-)
Gary
>
> ajs6f
> ---------------------------------------------------------------------
> 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 Was: Prepare commons to JDK 9
Posted by ajs6f <aj...@apache.org>.
> On Mar 8, 2018, at 12:09 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> 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. 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 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.
>
> Gary
>
"breaks Maven plugins and tools left and right"
Yes. That's the point. That's perfectly fine. Kamila will find out which break, and how, and what options we have to deal with them, and when we might need to go upstream and come back, and she will document that, and she will do what work can be done now on those problems.
If Commons RDF does not release MR JARs as part of the GSoC project, but we do understand specifically and in detail why and what the blockers are, the project will have been a success. With respect, I think you are now objecting to a project that hasn't actually been proposed, for which success would be releasing MR JARs. _That is not what is being proposed._
ajs6f
---------------------------------------------------------------------
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 Was: Prepare commons to JDK 9
Posted by Gary Gregory <ga...@gmail.com>.
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. 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 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.
Gary
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9
Posted by ajs6f <aj...@apache.org>.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
On Wed, 7 Mar 2018 22:21:44 +0000, Stephen Colebourne wrote:
> On 7 March 2018 at 18:56, Ralph Goers <ra...@dslextreme.com>
> wrote:
>> Actually, you really do need to use a multi-release jar to include a
>> module-info class file. Otherwise it may be sitting alongside of
>> classes compiled for an earlier java release and various tools will
>> fail because of it.
>
> Then those tools need fixing.
>
> Using multi-release jar files doesn't really help either, as other
> tools don't understand those.
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)?
Regards,
Gilles
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by Stephen Colebourne <sc...@joda.org>.
On 7 March 2018 at 18:56, Ralph Goers <ra...@dslextreme.com> wrote:
> Actually, you really do need to use a multi-release jar to include a module-info class file. Otherwise it may be sitting alongside of classes compiled for an earlier java release and various tools will fail because of it.
Then those tools need fixing.
Using multi-release jar files doesn't really help either, as other
tools don't understand those.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by ajs6f <aj...@apache.org>.
> On Mar 12, 2018, at 1:13 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On Mar 12, 2018, at 9:27 AM, Jörg Schaible <jo...@gmx.de> wrote:
>>
>> Hi Ralph,
>>
>> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>>>
>>> Actually, you really do need to use a multi-release jar to include a module-info class file. Otherwise it may be sitting alongside of classes compiled for an earlier java release and various tools will fail becaus of it.
>>
>> Not necessarily. XStream contains for more than a decade class files targeting different Java versions. Works normally fine as long as nobody tries to load a class that cannot handled by the current runtime. Android has its problems with it, but it has already problems with Java 8 ;-)
>
> You statement just proved my point. “Works fine as long as …”. So as soon as you want to support those various tools you have to stop doing that.
>
> Ralph
Is there actually a standard list of tools or other build apparatus that is to be supported by Commons releases? I can name lots and lots of tools that won't work with Java 7 or even earlier versions. Most of them don't matter at all. I'm not making a claim about any particular tool or toolchain (including Android), but a general point.
I'd like to understand when "if we try X, our artifacts won't work on Y" is a valid blocker for a Commons project. In this case, the project (as has been repeatedly explained) aims to do nothing more than understand the conditions for using X and how to meet them, so I don't see how Android's (or any other specific project's) problems are a blocker at all. If anything, concern with problems for Android usage should be assuaged by a project that will help turn up more data about those problems.
Adam Soroka ; ajs6f@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 12, 2018, at 9:27 AM, Jörg Schaible <jo...@gmx.de> wrote:
>
> Hi Ralph,
>
> On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>
>>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <sc...@joda.org>
>>> wrote:
>>>
>>> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
>>> six-month release which is about to be replaced by Java 10, which will
>>> then be replaced by Java 11. Thus, Java 8 is the only sensible baseline
>>> right now.
>>>
>>> 2) Compiling a single jar file such that it works on Java 8 but has a
>>> module-info.class for Java 9 using Maven is a right pain in the
>>> backside. Most maven plugins cannot seamlessly handle it making the
>>> pom.xml much more complex. Note that you do not need a multi-release
>>> jar file to make it work. See
>>> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
>>> <https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml>
>>
>> Actually, you really do need to use a multi-release jar to include a
>> module-info class file. Otherwise it may be sitting alongside of classes
>> compiled for an earlier java release and various tools will fail because
>> of it.
>
> Not necessarily. XStream contains for more than a decade class files targeting different Java versions. Works
> normally fine as long as nobody tries to load a class that cannot handled by the current runtime. Android has
> its problems with it, but it has already problems with Java 8 ;-)
You statement just proved my point. “Works fine as long as …”. So as soon as you want to support those various tools you have to stop doing that.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
On Wed, 07 Mar 2018 11:56:32 -0700 Ralph Goers wrote:
>> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <sc...@joda.org>
>> wrote:
>>
>> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
>> six-month release which is about to be replaced by Java 10, which will
>> then be replaced by Java 11. Thus, Java 8 is the only sensible baseline
>> right now.
>>
>> 2) Compiling a single jar file such that it works on Java 8 but has a
>> module-info.class for Java 9 using Maven is a right pain in the
>> backside. Most maven plugins cannot seamlessly handle it making the
>> pom.xml much more complex. Note that you do not need a multi-release
>> jar file to make it work. See
>> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
>> <https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml>
>
> Actually, you really do need to use a multi-release jar to include a
> module-info class file. Otherwise it may be sitting alongside of classes
> compiled for an earlier java release and various tools will fail because
> of it.
Not necessarily. XStream contains for more than a decade class files targeting different Java versions. Works
normally fine as long as nobody tries to load a class that cannot handled by the current runtime. Android has
its problems with it, but it has already problems with Java 8 ;-)
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Prepare commons to JDK 9
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <sc...@joda.org> wrote:
>
> 1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
> six-month release which is about to be replaced by Java 10, which will
> then be replaced by Java 11. Thus, Java 8 is the only sensible
> baseline right now.
>
> 2) Compiling a single jar file such that it works on Java 8 but has a
> module-info.class for Java 9 using Maven is a right pain in the
> backside. Most maven plugins cannot seamlessly handle it making the
> pom.xml much more complex. Note that you do not need a multi-release
> jar file to make it work. See
> https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml <https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml>
Actually, you really do need to use a multi-release jar to include a module-info class file. Otherwise it may be sitting alongside of classes compiled for an earlier java release and various tools will fail because of it.
Ralph
Re: Prepare commons to JDK 9
Posted by Stephen Colebourne <sc...@joda.org>.
1) Moving to Java 9 as a base would be a terrible choice. Java 9 is a
six-month release which is about to be replaced by Java 10, which will
then be replaced by Java 11. Thus, Java 8 is the only sensible
baseline right now.
2) Compiling a single jar file such that it works on Java 8 but has a
module-info.class for Java 9 using Maven is a right pain in the
backside. Most maven plugins cannot seamlessly handle it making the
pom.xml much more complex. Note that you do not need a multi-release
jar file to make it work. See
https://github.com/ThreeTen/threeten-extra/blob/master/pom.xml
3) It is yet to be demonstrated that JPMS is going to be widely used.
To release a jar file with JPMS module-info.class, it requires that
ALL dependencies are also JPMS modules with either module-info.class
or Automatic-Module-Name in the manifest. Most projects are nowhere
near this position yet.
Right now the plan for commons should be simple:
- add Automatic-Module-Name to MANIFEST.mf to lock down the module name
- if the project has no dependencies and runs on Java 6 or later,
consider adding a module-info.java, with the awareness that this is a
complex task
Stephen
On 7 March 2018 at 03:46, Kamila Molina Orellana
<ka...@gmail.com> wrote:
> Dear all,
>
> As an idea for GSoC that came up in [1], we want to settle some guidelines
> that other commons projects might follow to make the shift. We came up with
> some ideas in [2]. I wanted to ask about some experience you have had while
> moving to JDK 9 in other commons-projects.
>
> I wanted to propose this:
>
> 1. Make the movement of commons-rdf to JDK 9 generating modules
> descriptions automatically through Maven.
> 2. Generate integration tests to guarantee that modules are working as
> expected with JDK 9.
> 3. Maybe have multi-release JARs?
>
> Since other commons projects follow a similar structure, we can generate
> some documentation in a wiki-like media. So, they can make the shit to JPMS
> or at least have a guideline. Or I can contribute :D.
>
> Wha do you think?
>
> Regards,
> ~Kamila.
>
>
> [1] https://issues.apache.org/jira/browse/COMMONSSITE-103
> [2] https://issues.apache.org/jira/browse/COMMONSRDF-75
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org