For one of the libraries we maintain, we currently publish to a private repo using:

publishing {
    publications {
        mavenJava(MavenPublication) { publication ->
            artifactId = 'lib-name'
            from components.java
            versionMapping {
                usage('java-api') {
                    fromResolutionOf('runtimeClasspath')
                }
                usage('java-runtime') {
                    fromResolutionResult()
                }
            }
        }
    }
    repositories {
        maven {
            ....
        }
    }
}

This works fine. Now we are obfuscating the code using proguard and we updated this to use the jar generated by the proguard task:

publishing {
    publications {
        mavenJava(MavenPublication) { publication ->
            artifactId = 'lib-name'
            
            artifact(tasks.proguard.outputs.files[0]) {
                builtBy(tasks.proguard)
            }
            versionMapping {
                usage('java-api') {
                    fromResolutionOf('runtimeClasspath')
                }
                usage('java-runtime') {
                    fromResolutionResult()
                }
            }
        }
    }
    repositories {
        maven {

    }
}

This does work in the sense that it publishes the jar generated by proguard but importantly it doesn't generate the same

.pom

file with all the associated dependencies as the one generated from the

components.java

artifact (and the sources jar but this is less important at the moment). Is there a way to use the jar from the proguard task but still have all the other parts of the publication from the components.java artifact ? I tried using both artifacts at the same time but that generated an error -

Invalid publication 'mavenJava': multiple artifacts with the identical extension and classifier ('jar', 'null').

. Adding a classifier to the proguard artifact works but then both jars are published and the proguard jar has the classifier appended to the filename. I also tried adding the

pom {}

element to the publication and removing the

components.java

artifact but that generated the pom but without all the dependencies that are present when generated from the

components.java

artifact. I am currently looking into just copying jars around but was wondering if there was a better way using the artifacts?

Using

artifact(...)

in a publication is seldomly the right thing to do. It literally means "publish this artifact" and that's it, no dependencies, no proper variant, nothing. Similarly, if you use

artifact(sourcesJar)

you only publish that jar in addition wihout having a proper sources variant that could then be resolved by Gradle consumers using variant-aware resolution. If you want a proper POM and proper Gradle Module Metadata, you should instead model a proper component like the

java

component and publish that. Also doing so is only really helpful if you want to publish to separate coordinates, publishing two publications to the same coordinates also does not produce the expected result. So maybe you instead want to model a proper feature variant that is published alongside your normal artifacts and can be resolved by Gradle consumers using variant-aware resolution. If you want to only publish this one jar and not the original jar to the coordinates, you instead probably want to remove the artifact from the

java

component and instead add the other jar as artifact to the respective variants. Btw. also setting group / artifact / version inside the publication is actually bad practice and can bite later, for example if you (or someone else) wants to use that build in a composite build, as then you usually need manual dependency substitution instead of it just working. So better make sure that the project name is equal to the artifact id at which you want to publish.

Many thanks for your reply. I will initially look into how to remove the artifact from the java component and replace it with the proguard artifact. I will also look into the other items you mentioned regarding the bad practice items