> ...You might get away with `--limit-modules
> java.se` and patching java.xml...
„--limit-modules java.se“ wasn't enough. To get the java launcher
past some „error: ...“ messages, I needed to add a few more modules:
„--limit-modules java.se,jdk.compiler,jdk.zipfs“.
But then I was back to the same ResolutionException blocker that had
originally caused me to lose the will to live:
$ java -ea --limit-modules java.se,jdk.compiler,jdk.zipfs --patch-module
java.xml=lib\gradle-api-6.0-rc-2.jar src\eg\UnPatchable.java
Exception in thread "main" java.lang.module.ResolutionException: Module
gradle.api contains package org.w3c.dom.views, module java.xml exports
package org.w3c.dom.views to gradle.api
at
java.base/java.lang.module.Resolver.resolveFail(Resolver.java:885)
at
java.base/java.lang.module.Resolver.failTwoSuppliers(Resolver.java:789)
at
java.base/java.lang.module.Resolver.checkExportSuppliers(Resolver.java:737)
at java.base/java.lang.module.Resolver.finish(Resolver.java:362)
at
java.base/java.lang.module.Configuration.<init>(Configuration.java:141)
at
java.base/java.lang.module.Configuration.resolve(Configuration.java:424)
at
java.base/java.lang.module.Configuration.resolve(Configuration.java:256)
at eg.UnPatchable.main(UnPatchable.java:24)
It really is impossible to patch Gradle's API JAR, it looks like :(
Please tell me I'm wrong?
> ...I'm not sure what to say about xml-apis. I assume it ends up in
> gradle-api-6.0-rc-2.jar because something depends on it. I can't think
> why anything might be depending on this relic in 2019. It might be
> useful track down why it is included in the first place.
Gradle makes heavy use a lot of stuff in the javax.xml.* and org.w3c.*
packages internally [1] And, again, this shaded jar we're talking about
is generated on demand — IFF a Gradle plugin author happens to have
applied a specific internal Gradle plugin that is only ever applied to
assist in the development of custom Gradle plugins. So this api jar is
not actually „distributed“ in the same sense that other artifacts
are normally „distributed“ — through a public repository, say.
I can't say with 100% certainty, but I _think_ everything contained in
this shaded JAR is expected to never show up on the classpath(s) of end
users of my plugin for example.
So I think you're right, Alan. Those xml-apis dependencies in that
shaded JAR are probably just one of a ton of other rebundled internal
dependencies that Gradle itself needs to support the plugin development
use case.
----
[1] http://bit.ly/xmlapisHits
-------- Original Message --------
Subject: RE: Seeking Assurance That Patching gradle-api-6.{...}.jar Is
At Least Technically Possible - Somehow
From: "Plugins" <plug...@lingocoder.com>
Date: Tue, November 12, 2019 6:30 am
To: "Alan Bateman" <alan.bate...@oracle.com>,
jigsaw-dev@openjdk.java.net
> ...You might get away with `--limit-modules
> java.se` and patching java.xml...
Awesome! I will give that a shot. Many thanks!
> ...it would be really odd to have classes for Gradle,
> SLF4J, JodaTime, and more in the java.xml module...
I take your advice from JEP 261's „Patching module content“ section
to heart: „The --patch-module option is intended only for testing and
debugging. Its use in production settings is strongly discouraged“ [1]
My reasons for patching is only to allow temporary access to the classes
under test by unit tests. Since those are conventionally in the same
package but in two different Gradle source sets.
> ...It might be useful track down why it is included in the first place...
I agree. I will see what I can find out about that.
Thanks for the Eclipse bug link too, Alan. Super informative!
[1] http://bit.ly/JEP261Patch
-------- Original Message --------
Subject: Re: Seeking Assurance That Patching gradle-api-6.{...}.jar Is
At Least Technically Possible - Somehow
From: Alan Bateman <alan.bate...@oracle.com>
Date: Tue, November 12, 2019 4:50 am
To: Plugins <plug...@lingocoder.com>, jigsaw-dev@openjdk.java.net
On 12/11/2019 09:19, Plugins wrote:
> :
>
>
> If you can answer a few questions for me please Alan, you could help
> salvage the little sanity I have left after wrestling with this:
>
> 1. What's the correct command to patch javax.xml and jdk.xml.dom with
> Gradle's API JAR?
> 2. If it is actually impossible to patch either of them with Gradle,
> what's your best guess for why that might be?
> 3. How can I _exclude_ javax.xml and jdk.xml.dom from the module graph?
> • I have already tried --limit-modules, but haven't had any luck
>
> In the meantime, I will try to muster up the will to report the issue
> to the Gradle devs.
>
You can't use --patch-module to augment both java.xml and jdk.xml.dom
with the classes/resources from gradle-api-6.0-rc-2.jar as that will
create a split package issue. You might get away with `--limit-modules
java.se` and patching java.xml but it would be really odd to have
classes for Gradle, SLF4J, JodaTime, and more in the java.xml module. I
think the only sane approach is to deconstruct gradle-api-6.0-rc-2.jar
so that the components it contains can be used as automatic modules.
I'm not sure what to say about xml-apis. I assume it ends up in
gradle-api-6.0-rc-2.jar because something depends on it. I can't think
why anything might be depending on this relic in 2019. It might be
useful track down why it is included in the first place.
-Alan
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536928
