I'm finding MavenDeployer awkward. Am I using it correctly?

Old Forum Archive
1

According to the APi documentation, RepositoryHandler.mavenDeployer will add a new MavenDeployer for each call*. I’m in a situation in which I want to define the default MavenDeployer behaviour in the root project and then tweak it for certain subprojects in their respective build scripts.

The way I’m doing this is awkward:

subprojects {
  uploadArchives {
    project.mavenDeployerRef = repositories.mavenDeployer {
       ...

Then in a subproject I do this: (because the project name is good for the IDE, but for historic reasons the artifactId is different)

mavenDeployerRef.pom.artifactId = '...'

Another pain point is that I haven’t found a way to remove the jar artifact from archives if my upload artifact is a zip. The archives set is, IIRC, an UnmodifiableSet, so I can’t remove anything from as it (as was suggested in an old mailing list archive post). The war plugin does something to avoid this, but I haven’t dug into the code.

Anyway, the solution I’m left with is ugly, and forces me to define the artifactId yet again (as I defined the conventional in the root project):

mavenDeployerRef.pom('zip').artifactId = '...'

If I don’t define it I get this error:

A POM cannot have multiple artifacts with the same type and classifier.

That’s everything. Am I missing some ways to improve on this? Cheers!

2

I’ve found a way to remove the jar from the archives. It’s using the deprecated removeArtifact method but works with the current 1.0-milestone-5 snapshot:

configurations.archives.removeArtifact(
   configurations.archives.allArtifacts.find {
    it.file == tasks.jar.archivePath } )

I can also confirm that via the Decorated version of DefaultConfiguration, getArtifacts() returns a java.util.Collections$UnmodifiableSet.

3

This has all changed quite recently.

From m4 on the collection returned by getArtifacts() is live, so can be mutated. In m5 it’s one of these fellas:

http://gradle.org/releases/latest/docs/javadoc/org/gradle/api/artifacts/PublishArtifactSet.html

It seems that you’ve found a workable solution here. I’ll mark as answered, but just post back if it’s not working for you.

4

Thanks, Luke.

Is there any way to improve on the first half of my question? Re:

project.mavenDeployerRef = repositories.mavenDeployer { ... }
5

One thing you could do is abstract this a little, which I do in the Geb build.

See: https://github.com/geb/geb/blob/master/build.gradle#L245

Which gives me a modifyPom() method to use in other projects…

Example here: https://github.com/geb/geb/blob/master/module/geb-core/geb-core.gradle#L6

But underlying all of this is some deficiencies in the way Gradle models publications which we are aware of and working towards fixing.

6

That’s a powerful idiom. That will work well for me. Thank you, Luke.