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...

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