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