Hello again James!
Your updated comment its pretty similar to what I have actually (great minds!).
I should have waited to ask this. I am still in the middle of prototyping this and it is fairly complex. I’ll let it percolate for a bit and get back.
As background, this comes from stuff I am prototyping related to the JakartaTransformer tool. You can read some of the back-ground if you wish @ Additional JAR file - variant versus classifier - #2 by Steve_Ebersole
The structure we came up with so far (happy to hear better ways) is to create a “shadow” of the projects from our build that we want to transform. E.g., we need to transform hibernate-core, so we have a separate project named hibernate-core-jakarta which defines a dependency on hibernate-core. hibernate-core-jakarta has absolutely no sources of its own. It’s whole purpose is to be the place where this transformation happens and at the end of the day to present the transformations as its own artifacts. In between is pretty wide open. We have a mostly working solution, I’m just trying to Gradle-fy it.
The tricky part is handling transitive dependencies. E.g. Hibernate exposes some things from JTA. Like all other EE specs, that one now has a Jakarta EE parallel. So when we transform our JAR, we also need to be able to adjust those GAVs as well. At the moment, we basically have to manually rewrite the hibernate-core dependencies block in hibernate-core-jakarta to work around this. Though I highly suspect I will be able to handle those transitively during resolution to dynamically swap GAV for select dependencies