Adding an archive from a subproject's task causes a build failure

[LunNova]

def gradlePluginJar = tasks.getByPath(':gradle-plugin:jar')
gradlePluginJar.getArchiveClassifier().set("gradle-plugin")
artifacts {
	add("archives", gradlePluginJar)
}

Causes a failure https://travis-ci.com/MinimallyCorrect/Mixin/jobs/277408476 :

org.gradle.api.publish.maven.InvalidMavenPublicationException: Invalid publication 'javaLibrary': POM file is invalid. Check any modifications you have made to the POM file.
...
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Duplicated tag: 'packaging' (position: START_TAG seen ...<name>gradle-plugin</name>\n  <packaging>... @22:14) 

Thought this was the same issue as #847 but it still happens with shipkit 2.2.7.

[LunNova]

The code here always configures a publication:

shipkit/subprojects/shipkit/src/main/groovy/org/shipkit/internal/gradle/java/JavaPublishPlugin.java

Line 58 in 56dd15e

GradleDSLHelper.publications(project, publications -> {

There doesn't seem to be anyway to avoid or customize this. You can change the publication afterwards, but that doesn't necessarily work (if you needed to avoid one of the lines there, it's already done :/)

[mockitoguy]

Sorry about the issue! Looking into it now.

[mockitoguy]

Hey @nallar, can you provide repro case (a branch in you repo "MinimallyCorrect/Mixin" would be perfect)?

You're right, there is no way to avoid this opinionated configuration. The only option is to assemble the plugins yourself and choose plugins you want to use. E.g. don't apply high-level "org.shipkit.java", rather apply the individual shipkit plugins.

Due to those problems, Shipkit will be evolving into many smaller plugins that are easier to configure and are more decoupled.

Thanks for using Shipkit!

[LunNova]

Doesn't seem possible to avoid the JavaPublishPlugin being applied without also avoiding the JavaBintrayPlugin, so lose most of shipkit :(

The failing example should still be available at this commit: MinimallyCorrect/Mixin@9cd3429

Maybe it's better to explain what we want to do at a high level, rather than the errors encountered.

We need to customize what the published artifacts are, including being able to get the main artifact from a different place than the jar task's output.

For this project, the hope was to use the shadow plugin so the main jar would include a relocated org.objectweb.asm to avoid conflicts.

https://imperceptiblethoughts.com/shadow/publishing/#publishing-with-maven-publish-plugin

Another project which would require getting the main jar from a different place 'remaps' the main jar from readable names to ones matching obfuscated names (for minecraft mods) (a slight simplification as there are 'intermediate' names used... but close enough). The remapped jar should be published as the main artifact of the project in this case.

e: In the project with the failure shipkit only gets applied if on CI to avoid slowing down the build locally. Configuration stuff's here: https://github.com/MinimallyCorrect/DefaultsPlugin/blob/master/src/main/java/org/minimallycorrect/gradle/ShipkitExtensions.java

[LunNova]

Urgh, it seems like to a large extent this is caused by problems with gradle's model, not shipkit?

If gradle had a standardised way of adding additional tasks which post process the main jar for the java component it'd solve this and similar trouble with every other plugin which makes similar assumptions that the jar task's output is the right thing to use? :c

[mockitoguy]

Looking into it...

[mockitoguy]

We need to customize what the published artifacts are, including being able to get the main artifact from a different place than the jar task's output.

So... you want to leverage the most of shipkit but you want to publish a different artifact than the "jar" task?

Did you try this:

def pub = publishing.publications.getByName('javaLibrary')
pub.artifacts.clear()
//... add artifacts you want

Api docs:

• https://docs.gradle.org/current/dsl/org.gradle.api.publish.PublicationContainer.html
• https://docs.gradle.org/current/javadoc/org/gradle/api/publish/maven/MavenPublication.html
• https://docs.gradle.org/current/javadoc/org/gradle/api/publish/maven/MavenArtifactSet.html

Do you want to put together a small project without shipkit somewhere on the side? I'd like to understand what how you want to customize publications / the default java plugin tasks.

Let's solve this use case and use it as an example. Perhaps there's a path to clean configuration here :-)

[mockitoguy]

Hi @nallar, any progress? Cheers!

[LunNova]

@mockitoguy not yet, sorry. Have ended up working on some other things which don't even involve java or gradle. Will update when get to it.

[LunNova]

haven't made progress on code but have some thoughts on how to make this more configurable:

Make a way to tell shipkit which publication(s) to use, instead of creating its own?

This would also involve not using the bintray plugin. It's possible to publish to bintray as a normal maven deploy. Would that cause problems?