Prepare commons to JDK 9

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Prepare commons to JDK 9

Kamila Molina Orellana
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
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

garydgregory
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 <
[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

jodastephen
In reply to this post by Kamila Molina Orellana
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
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Gilles Sadowski
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
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Ralph Goers
In reply to this post by jodastephen


> On Mar 7, 2018, at 2:47 AM, Stephen Colebourne <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

jodastephen
On 7 March 2018 at 18:56, Ralph Goers <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Gilles Sadowski
Hello.

On Wed, 7 Mar 2018 22:21:44 +0000, Stephen Colebourne wrote:

> On 7 March 2018 at 18:56, Ralph Goers <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons to JDK 9

Ralph Goers
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 <[hidden email]> wrote:
>
> Hello.
>
> On Wed, 7 Mar 2018 22:21:44 +0000, Stephen Colebourne wrote:
>> On 7 March 2018 at 18:56, Ralph Goers <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

Adam Soroka
In reply to this post by Gilles Sadowski
> On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]> 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 ; [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

garydgregory
On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:

> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]> 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 ; [hidden email]


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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

Adam Soroka

> On Mar 8, 2018, at 12:09 PM, Gary Gregory <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

Gilles Sadowski
In reply to this post by garydgregory
On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:

> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>
>> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>> 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 ; [hidden email]
>
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

garydgregory
In reply to this post by Adam Soroka
On Thu, Mar 8, 2018 at 10:21 AM, ajs6f <[hidden email]> wrote:

>
> > On Mar 8, 2018, at 12:09 PM, Gary Gregory <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

garydgregory
In reply to this post by Gilles Sadowski
On Thu, Mar 8, 2018 at 10:29 AM, Gilles <[hidden email]>
wrote:

> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>
>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>
>> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>>> 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 ; [hidden email]
>>>
>>
>>
>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Gilles Sadowski
On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:

> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
> <[hidden email]>
> wrote:
>
>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>
>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>
>>> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>>>> 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 ; [hidden email]
>>>>
>>>
>>>
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

garydgregory
On Thu, Mar 8, 2018 at 10:58 AM, Gilles <[hidden email]>
wrote:

> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>
>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <[hidden email]>
>> wrote:
>>
>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>
>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>>
>>>> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>>>>
>>>>> 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 ; [hidden email]
>>>>>
>>>>>
>>>>
>>>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9 Was: Prepare commons to JDK 9

Adam Soroka
In reply to this post by garydgregory

> On Mar 8, 2018, at 12:48 PM, Gary Gregory <[hidden email]> wrote:
> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <[hidden email]>
> 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 ; [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Gilles Sadowski
In reply to this post by garydgregory
On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:

> On Thu, Mar 8, 2018 at 10:58 AM, Gilles
> <[hidden email]>
> wrote:
>
>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>
>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
>>> <[hidden email]>
>>> wrote:
>>>
>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>
>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>>>
>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles
>>>>> <[hidden email]>
>>>>>
>>>>>> 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 ; [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Ralph Goers


> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]> wrote:
>
> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles <[hidden email]>
>> wrote:
>>
>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>>
>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>>
>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>>>>
>>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles <[hidden email]>
>>>>>
>>>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Prepare commons RDF to JDK 9

Gilles Sadowski
On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:

>> On Mar 8, 2018, at 11:06 AM, Gilles <[hidden email]>
>> wrote:
>>
>> On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
>>> On Thu, Mar 8, 2018 at 10:58 AM, Gilles
>>> <[hidden email]>
>>> wrote:
>>>
>>>> On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
>>>>
>>>>> On Thu, Mar 8, 2018 at 10:29 AM, Gilles
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
>>>>>>
>>>>>> On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <[hidden email]> wrote:
>>>>>>>
>>>>>>> > On Mar 8, 2018, at 8:33 AM, Gilles
>>>>>>> <[hidden email]>
>>>>>>
>>>>>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12