Seeking Assurance That Patching gradle-api-6.{...}.jar Is At Least Technically Possible - Somehow

[Plugins]

> ...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" <plugins at lingocoder.com>
Date: Tue, November 12, 2019 6:30 am
To: "Alan Bateman" <Alan.Bateman at oracle.com>,
jigsaw-dev at 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.Bateman at oracle.com>
Date: Tue, November 12, 2019 4:50 am
To: Plugins <plugins at lingocoder.com>, jigsaw-dev at 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