POM doesn't upload

swpalmer · February 11, 2012, 2:50am

I’ve made a small multi-project gradle build to upload JavaFX runtimes for Windows, Linux and Mac to our internal Artifactory repo. It is a simeple thing hard-coded to grab the windows files from my JavaFX Runtime install and the Linux and Mac files from folders on the same machien where I have unzipped the JAvaFX download available for those platforms. The project is split into a root project with no artifact and two sub-projects. One that references the jfxrt.jar for each platform and makes an “archive” of it with appropriate classifiers to denote the target platform (with an artifactId of “jfxrt”), another sub-project that makes a zip of the native code, one for each platform, and gives them classifiers for each platform and CPU architecture. When the project runs I can see in the “build” folder of the sub projects that a “pom-default.xml” file has been created, but that file does not get uploaded, even thou all the archives do. I can’t figure out why.

Here’s what my project looks like:

jfxrt/

settings.gradle

build.gradle

jfxrt/

build.gradle

jfxrt-native/

build.gradle

the root build.gradle file contains the following:

defaultTasks 'upload'
  version = "2.1.0.12"
  dependsOnChildren()
  configurations {
    deployerJars
}
dependencies {
    deployerJars "org.apache.maven.wagon:wagon-http:1.0-beta-2"
}
  subprojects {
 apply plugin: 'maven'
 groupId = "javafx"
 artfactBaseName = "jfxrt"
   uploadArchives {
  repositories {
   mavenDeployer {
    repository(url: "http://dcm-maven-repo/ext-release-local/")
    pom.groupId = project.groupId
   }
  }
 }
}

The jfxrt/build.gradle file contains:

def windowsJar = file("C:\Program Files (x86)\Oracle\JavaFX 2.1 Runtime\lib\jfxrt.jar")
def linuxJar = file("C:\Users\scott.palmer\Downloads\javafx-sdk${rootProject.version}-beta-linux\rt\lib\jfxrt.jar")
def macJar = file("C:\Users\scott.palmer\Downloads\javafx-sdk${rootProject.version}-beta-mac\rt\lib\jfxrt.jar")
  artifacts {
 archives(windowsJar) {
  name project.artfactBaseName
  version rootProject.version
  classifier = 'windows'
  type 'jar'
 }
 archives(linuxJar) {
  name project.artfactBaseName
  version rootProject.version
  classifier = 'linux'
  type 'jar'
 }
 archives(macJar) {
  name project.artfactBaseName
  version rootProject.version
  classifier = 'mac'
  type 'jar'
 }
}

and finally the jfxrt-native/build.gradle file contains:

version rootProject.version
   task windowsNativeZip(type: Zip) {
 baseName = project.artfactBaseName+"-native"
 classifier = "windows-x86"
 version = rootProject.version
    from("C:\Program Files (x86)\Oracle\JavaFX 2.1 Runtime\bin")
 include("*.dll")
 include("*.exe")
}
  task linuxNativeZip(type: Zip) {
 baseName = project.artfactBaseName+"-native"
 classifier = "linux-x86"
 version = rootProject.version
    from("C:\Users\scott.palmer\Downloads\javafx-sdk${rootProject.version}-beta-linux\rt\lib\i386")
 include("*.so")
}
  task macNativeZip(type: Zip) {
 baseName = project.artfactBaseName+"-native"
 classifier = "mac-x86_64"
 version = rootProject.version
    from("C:\Users\scott.palmer\Downloads\javafx-sdk${rootProject.version}-beta-mac\rt\lib")
 include("*.dylib")
}
  artifacts {
 archives windowsNativeZip
 archives linuxNativeZip
 archives macNativeZip
}

All of the jars/zips upload properly, but no pom is uploaded for either artifact (jfxrt or jfxrt-native). In the sub-projects after a build

jfxrt/build/pom-default.xml

and

jfxrt-native/build/pom-default.xml both exist. The contents appears to be reasonable.

Could somebody point me in the right direction?

wroosenburg · February 13, 2012, 3:17pm

Well, you have a typo in basename (project.artfactBaseName)

swpalmer · February 13, 2012, 4:06pm

True, but it is consistently wrong the same name is used to define it and reference it, so that isn’t likely an issue.

swpalmer · February 14, 2012, 6:51pm

Anyone? So close, and I’m sure I’m missing something very simple…

Peter_Niederwieser · February 14, 2012, 7:09pm

Judging from your build file, the POMs don’t need to contain much information anyway. Therefore, one solution would be to hand code three POMs and attach them to the configurations. Alternatively, study the Maven chapter in the user guide, especially how to generate multiple POMs per project (44.6.4.1).

swpalmer · February 14, 2012, 8:07pm

Well Gradle is already generating POMs. Calling them pom-default.xml … but it doesn’t upload them. I did see that section of the user guide, but thought I was working around it with the sub-projects (one pom per sub-project).

Peter_Niederwieser · February 14, 2012, 8:32pm

I did see that section of the user guide, but thought I was working around it with the sub-projects (one pom per sub-project).

I see three artifacts (windowsJar, linuxJar, macJar) being published in the same project. Aren’t you trying to create a POM for each of them?

Well Gradle is already generating POMs. Calling them pom-default.xml … but it doesn’t upload them.

Are you sure these are the POMs you expect to be generated? Do their contents match your expectations?

swpalmer · February 14, 2012, 8:39pm

Yes. The content looks correct to me. All it has is the groupId, artifactId, and version of the zip/jar that I copied.

swpalmer · February 14, 2012, 8:40pm

Note that the three jars are the same artifactId each with a distinct classifier to differentiate the platforms. That is valid for Maven as I understand it.

Peter_Niederwieser · February 14, 2012, 9:52pm

Note that the three jars are the same artifactId each with a distinct classifier to differentiate the platforms. That is valid for Maven as I understand it.

That’s fine, but you’ll still need to publish a separate POM for each of them.

swpalmer · February 15, 2012, 1:49am

Really? Maven itself does not appear to publish separate POMs when an artifact has several files with different classifiers (e.g. blah.1.0.jar, blah-1.0-javadoc.jar, blah-1.0-sources.jar).

Take a look at Maven Central http://search.maven.org/#browse and browse to maven/maven-model/3.0.2/ for example. You will find this:

  maven-metadata.xml 24-Apr-2007 170 B  maven-metadata.xml.md5 24-Apr-2007 126 B  maven-metadata.xml.sha1 24-Apr-2007 134 B  maven-model-3.0.2-sources.jar 24-Apr-2007 115.2 K  maven-model-3.0.2-sources.jar.md5 24-Apr-2007 32 B  maven-model-3.0.2-sources.jar.sha1 24-Apr-2007 40 B  maven-model-3.0.2.jar 24-Apr-2007 179.5 K  maven-model-3.0.2.jar.md5 24-Apr-2007 32 B  maven-model-3.0.2.jar.sha1 24-Apr-2007 40 B  maven-model-3.0.2.pom 24-Apr-2007 5.3 K  maven-model-3.0.2.pom.md5 24-Apr-2007 32 B  maven-model-3.0.2.pom.sha1 24-Apr-2007 40 B

Peter_Niederwieser · February 15, 2012, 2:05am

‘-sources’ and ‘-javadoc’ are so-called secondary artifacts. I don’t think this translates to your situation, unless you don’t need transitive dependency management. In that case you could probably get away without publishing any POM at all.

Peter_Niederwieser · February 15, 2012, 2:40am

I’ve googled some more and you may be right. Looks like there is just one POM whose name doesn’t contain the classifier.

swpalmer · February 15, 2012, 2:45am

Then I can stop making my test case to prove (to myself as well as you) that I wasn’t crazy

So what does this mean in the context of what Gradle is doing with my project as shown above? The pom is there, so it seems so close…

Peter_Niederwieser · February 15, 2012, 4:26am

I don’t know. Maybe it’s a problem with using the Maven plugin without the Java plugin. A small, self-contained example build demonstrating the problem would help. Meanwhile I’d commit the POM, add it as an artifact, and be done with it.

swpalmer · February 15, 2012, 2:04pm

Okay. I just tried a trimmed down example. I eliminated one sub-project (‘jfxrt-native’ from the example above) and I eliminated all but one of the artifacts… so I only have the one windows jar.

It still doesn’t upload the POM.

The root project is the same as shown at the beginning of this thread. The one and only sub-project looks like this:

def windowsJar = file("C:\Program Files (x86)\Oracle\JavaFX 2.1 Runtime\lib\jfxrt.jar")
  artifacts {
 archives(windowsJar) {
  name project.artfactBaseName
  version rootProject.version
  classifier = 'windows'
  type 'jar'
 }
}

Is that a suitable self-contained example?

swpalmer · February 22, 2012, 6:37pm

Okay, I have tried again with a trivial project. A POM is generated (as above), but it isn’t uploaded.

Here is my self-contained example:

// Test upload to Maven
apply plugin: 'maven'
defaultTasks 'upload'
  version = "1.0.0"
groupId = "testing"
   configurations {
    deployerJars
}
  dependencies {
    deployerJars "org.apache.maven.wagon:wagon-http:1.0-beta-2"
}
  // change this path to test
def windowsJar = file("C:\Program Files (x86)\Oracle\JavaFX 2.1 Runtime\lib\jfxrt.jar")
  artifacts {
 archives(windowsJar) {
  name "testupload"
  classifier = 'windows'
  type 'jar'
 }
}
  uploadArchives {
 repositories {
  mavenDeployer {
   repository(url: "http://url-to-artifactory/ext-release-local/")
   pom.groupId = groupId
  }
 }
}

gavares · February 22, 2012, 8:55pm

I’m also having a similar problem with a project that creates only a zip artifact. Artifact is created properly, a pom is generated under build/poms/ but no pom is uploaded to my Nexus repo.

This causes a problem with IVY based projects which depend on the zip artifact. When IVY fails to locate the pom file, it attempts to resolve a jar artifact which, in this case, doesn’t exist. The IVY resolution then fails.

If I could just convince Gradle to upload a POM file that had the packaging field property set, I think it would solve my problem.

My build file:

apply 'maven'
                                                                                                                          group="com.org.group"
                                                                                                 version="1.0-SNAPSHOT"
                                                                                                archivesBaseName="group-server"
                                                                                            packaging="zip"
                                                                                                                                                                                                                               configurations {
                                                                                                        dist
                                                                                                                }
                                                                                                                                                                                                                                             dependencies {
                                                                                                          dist group:"com.org.group",
 name:"group-server",
version: "1.0-SNAPSHOT"
                                            }
                                                                                                                                                                                                                                             task createDist(type: Zip) {
         classifier = "dist"
                                                                                     from ("src/dist/") {
                                                                                                    include ("**/*")
                                                                                                      into( "" )
                                                                                                          }
                                                                                                                                                                                                                                             from( configurations.dist ) {
                                                                                           into( "lib/" )
                                                                                                      }
                                                                                                                   }
                                                                                                                                                                                                                                             artifacts{
                                                                                                              archives createDist
                                                                                                 }

wroosenburg · February 23, 2012, 9:25am

I had the same issue, see http://forums.gradle.org/gradle/topics/how_can_i_add_a_maven_classifier_property_upon_pom_generation

From what I understand from the Maven documentation, a POM is only generated for let’s say the base project. If you specify additional artifacts which only distinguish themselves using the classifier attributes (and not secondary artifacts such as source or javadocs) than usually no pom is generated. This is default Maven2 behaviour. Also, as another example, if I manually upload an artifact to Nexus/Artifactory and i specify a classifier attribute, it is not reflected in the POM, it is only used for jar-renaming purposes. I don’t know how the packaging attribute is handled…

Also if you look at the Gradle filter examples within the Maven chapters, you see that the examples sets a different version number on the artifacts, which results in an extra artifact with pom, because it is a different artifact, from a Maven perspective.

Apparently, some guys wants to change this behaviour within Maven3, so maybe you should have a look in the appropriate newsgroups. From my perspective, Gradle implements Maven2 behaviour.

swpalmer · February 23, 2012, 2:38pm

But Gradle is generating the needed POM. Classifiers are not reflected in the POM, that is normal. The only issue here is that the generated POM is not uploaded. That’s a bug, or I’m not doing something right to trigger the POM upload. After I run my gradle build I just have to rename the generated pom-default.xml to pom.xml and manually upload it to Artifactory and all is well. It’s just that I shouldn’t have to do that manually at all.

Topic		Replies	Views
What is simplest uploadArchives setup that will actually work, using only Java and Maven plugins? Old Forum Archive	11	5243	August 1, 2013
uploadArchives to Apache Archiva does not upload pom-file Old Forum Archive	3	2458	March 1, 2013
Maven publishing plugin doesn't upload generated POM file Old Forum Archive	4	4391	June 4, 2013
Setting pom properties in mavenDeployer removes all dependencies from the POM Bugs	2	2654	May 26, 2015
Uploading artifacts without a pom file Old Forum Archive	1	772	September 2, 2013

POM doesn't upload

Related topics