[GRADLE-1285] Cannot generate <packaging> element in Maven POM Created: 04/Jan/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.9.1
Fix Version/s: None

Type: Bug
Reporter: Peter Niederwieser Assignee: Unassigned
Resolution: Won't Fix Votes: 4


 Description   

I've tried to set the POM's packaging in either of the two ways shown below, but the resulting POM doesn't have a <packaging> element:

apply plugin: "maven"

install {
  repositories.mavenInstaller {
    pom {
      packaging = "pom" // has no effect

      project {
        packaging "pom" // has no effect
      }
    }
  }
}


 Comments   
Comment by Peter Niederwieser [ 04/Jan/11 ]

pom.model.packaging = "pom" doesn't work either

Comment by John Roth [ 24/Jan/11 ]

This is quite frustrating. But actually almost documented in example 224 of the maven plugin docs. Technically documented, if not morally so.

In general, Gradle seems to thinks it knows how to handle the packaging element. It also thinks "jar" is the default, so that it does not need to write it. (Which is not totally wrong, I read elsewhere.)

So, a workaround is

repositories.mavenDeployer {
repository(url: "file://${buildDir}/distTmp/pseudoMaven2Repo" );
pom.project

{ name "yourname" }

pom.whenConfigured(

{pom -> pom.packaging = "foojar"; }

);
}

except when the value of "packaging" is "jar." In that case, we can hack up the string

pom.withXml(

{ z -> def sb = z.asString(); def a = sb.indexOf( "<name" ); // or whereever you want to put it. sb.insert( a, "<packaging>jar</packaging>\n " ); }

);

NB also withXml() does not supply a real XmlProvider as advertised; only asString()
works. So why not just supply the string builder?

– Anon.

Comment by Hans Dockter [ 24/Jan/11 ]

@John The XmlProvider does now do a better job (0.9.2.). See http://gradle.org/0.9.2/docs/javadoc/org/gradle/api/artifacts/maven/XmlProvider.html

Comment by Peter Niederwieser [ 05/Mar/11 ]

Digging deeper, I found the following:

1. For a project which has the Java plugin applied, Gradle will override any manually set packaging type (e.g. "pom") with "jar". This isn't totally wrong because Gradle will publish the Jar, even if it has size 0. If the Java plugin is not applied however, no publishing will take place. So it might not be possible at the moment to publish only a POM. Workaround is to abandon the parent POM and duplicate the information in every child POM.

2. Gradle never outputs <packaging>jar</packaging> because this is the default. (Actually it's the underlying Maven code that doesn't output this.) Except for aesthetic requirements, this shouldn't be a problem.

Comment by David Carr [ 12/Feb/13 ]

Unless I've missed something, this still affects Gradle 1.4. Here's the workaround that I'm using to output the "jar" packaging. It inserts the element right after the "version" tag.

pom.withXml { root ->
    def children = root.asNode().children()
    def versionIndex = children.indexOf(children.find {it.name().localPart == 'version'})
    children.add(versionIndex + 1, new Node(null, 'packaging', 'jar'))
}
Comment by Peter Niederwieser [ 13/Feb/13 ]

It shouldn't be necessary to do so, because <packaging>jar</packaging> is the default (like <scope>compile</scope> etc.). That's why the Maven (!) code used underneath doesn't write it to the file.

Comment by Ken [ 13/Mar/14 ]

I am trying to generate a Maven plugin using Gradle, so I need to be able to specify the packaging type as maven-plugin. Seems like it should be a simple thing to do, but this bug makes it more difficult.

Comment by Ryan McDonough [ 05/Nov/16 ]

I can confirm this is still very much an open issue. I'm not trying to generate a pom.xml with JAR packaging, but rather with pom packaging so that I can generate dependencies pom, much like what Spring is doing for several of their projects

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:51:39 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.