On Thu, 8 Mar 2018 17:17:40 -0700, Ralph Goers wrote:
On Mar 8, 2018, at 4:08 PM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Thu, 8 Mar 2018 15:09:18 -0700, Ralph Goers wrote:
On Mar 8, 2018, at 11:06 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Thu, 8 Mar 2018 11:01:08 -0700, Gary Gregory wrote:
On Thu, Mar 8, 2018 at 10:58 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
On Thu, 8 Mar 2018 10:48:28 -0700, Gary Gregory wrote:
On Thu, Mar 8, 2018 at 10:29 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
On Thu, 8 Mar 2018 10:09:22 -0700, Gary Gregory wrote:
On Thu, Mar 8, 2018 at 10:01 AM, ajs6f <aj...@apache.org>
wrote:
> On Mar 8, 2018, at 8:33 AM, Gilles
<gil...@harfang.homelinux.org>
given component and see if we want to only depend on
java.base or create
Maven modules to compartmentalize dependencies.
Then these modules can define "module-info" files, and an
actual
build will prove that the dependencies are as expected.
As Ralph as pointed out, you cannot generate a module-info file
without
also using an MR Jar unless you also want to make Java 9 your
base line.
Did you see, a few lines above: "[...] assuming JDK 9+ [...]"?
;-)
Related note: Java 9 is the target for compiling
"commons-rng-examples" (maven module)
in "Commons RNG" because one of the examples is composed of
JPMS modules (with "module-info" files) that depend on the
"official" artefacts (targeting Java 6) that declare an
"automatic module name" in the manifest.
Right now
https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=blob;f=pom.xml;h=06cc58c19b79af5cdf2f3d29d9a743c8adb2b548;hb=HEAD
shows Java 8 as the target.
Are you taking about changing that to Java 9?
I'll that choice to the Common RDF community but it seems that
this would
exclude a lot of users.
As for "Commons RNG", the purpose may just be to prove (by
usage) that the maven modules are also JPMS modules.
I am so confused. I am not sure what the goal is. Let me put it
this
way. Log4j 2 2.x supports Java 7+. We added support for Java 9 by
introducing a multi-release jar. Android developers can not use
any
version of Log4j since we did that. What I am saying is that if you
turn any jar into a multi-release jar it will no longer be usable
in
Android and there is no way around it until Android Studio is
fixed.
The problem is that the android tool inspects every class file in
the
jar even if it is located under META-INF and it dies if it sees a
Java
9 class.
Ralph
I've asked on this list about leveraging the new features of
JDK 9 in the upcoming release of [RNG]. When it came to
multi-release JAR, I trusted Gary's expedite answer ("Don't
do it") based, as yours, on experience. So, no issue.
Yet I also wanted to ensure that the maven modules were
JPMS-compliant: Would the declared "Automatic-Module-Name"
behave as expected on JDK 9?
No answer for that one. So I resorted to create a "dummy"
application (see "commons-rng-examples/examples-jpms").
I guess the same could be done for [RDF] unless there is a
smarter way. ;-)
We have not run into any problems with adding the
Automatic-Module-Name header to the manifest.
I'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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
