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
<kamila.molin...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
