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

[Plugins]

Hi Alan,

> ...why these API classes are still being distributed in 2019...
> ...none of this makes sense since Java SE 9 as both 
> JSR-206 and JSR-173 ceased to be standalone technologies...

You've put what I was thinking all along, into the perfect words there.
Thanks, Alan.

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.

TIA

-------- 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 1:04 am
To: Plugins <plugins at lingocoder.com>, jigsaw-dev at openjdk.java.net

On 12/11/2019 02:30, Plugins wrote:
> Hi all,
>
> I might have spoken too soon in my last October email [1]. Ever since,
> I've
> been having a hell of a time trying to get Gradle's so-called
> „shaded“ API jar
> to play nicely with the other modules in my JPMS-build-enabling Gradle
> plugin [2]
>
> For some reason, Gradle's generated artifact redundantly duplicates all
> the
> packages of two modules from the JDK: javax.xml and jdk.xml.dom.
The Gradle devs will know but I assume these are coming from the 
xml-apis-${version}.jar (Apache Xerces project). It's not clear, to me 
anyway, why these API classes are still being distributed in 2019. The 
XML processing API was added to Java SE 1.4, the XML stream API came a 
bit later. The XML APIs started out in Java SE as "standalone 
technologies" where they were in the JDK but could be upgraded by 
deploying a newer version with the endorsed standards override 
mechanism. It's possible, and probable, that developers have been 
deploying xml-apis on the class path and got lucky that it didn't cause 
problems. Anyway, none of this makes sense since Java SE 9 as both 
JSR-206 and JSR-173 ceased to be standalone technologies (see the final 
MR for both JSRs), and mechanism to upgrade them (the endorsed standards

override mechanism) has been removed.

-Alan.