Inconsistency between Jar Manifest class-path and dependencies

[jbartok]

While investigating a Gradle issue when using the Plugin Publish plugin together with the Shadow Plugin, we found an inconsistency in the Shadow plugin's code.

Our solution for it is just a workaround, we believe it would be good to fix the root cause, which is that while the gradleApi() is excluded as a dependency it is not excluded when the Jar Manifest class-path is being built. It should instead work as the java-gradle-plugin works.

Shadow Version

Latest.

Gradle Version

Not relevant.

Content of Shadow JAR (jar tf <jar file> - post link to GIST if too long)

See linked Gradle issue above. The problem is observed in the Manifest file of the Jar.

[johnrengelman]

Thanks @jbartok. I'm looking at the java-gradle-plugin and I'm wondering what the best way for me to implement the functionality here without using internal APIs.
Also, it's appears your first solution is a link into the close-source plugin-publish code, so I can't see that...Not sure it matters to see the workaround though.

[johnrengelman]

I really would love if these Gradle specific dependencies weren't special cases from normal dependencies (similar to gradle/gradle#24018).

[johnrengelman]

Just thinking out load here - but it also seems weird that Gradle uses the api configuration for adding gradleApi() to a plugin. Since this is never actually a dependency for a plugin (since it's provided by the running Gradle environment), its sort of a different beast. Would be interesting for Gradle to consider using a separate configuration and configuring compileClasspath to pull it in rather than treating gradleApi and groovyLocal the same as other dependencies.

[jbartok]

Also, it's appears your first solution is a link into the close-source plugin-publish code, so I can't see that...

Ahh, sorry, I always forget that the Plugin Publish plugin is closed-source (makes no actual sense, it's just that nobody has time to carve it out of that project...). This is the workaround I did in it:

[TWiStErRob]

without using internal APIs.

The only way I know is: componentFilter(SerializableLambdas.spec { it.displayName != "Gradle API" })
@jbartok Is there a way to get a ComponentIdentifier from dependencies.gradleApi()?
So we can do componentFilter(SerializableLambdas.spec { it != dependencies.gradleApi()....})

[johnrengelman]

Also if componentFilter checked if the passed in Spec implemented Serializable and then wrapped it with SerializableLambdas.spec if it didn’t, then that wouldn’t need to be elevated to public API while also not forcing users to make their own serializable version to support configuration caching.

[Goooler]

This should be fixed by #948.