POM doesn't upload

Old Forum
1

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?

2

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

3

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

4

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

5

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).

6

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).

7

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?

8

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

9

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.

10

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.

11

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
12

‘-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.

13

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

14

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

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…

15

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.

16

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?

17

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
  }
 }
}
18

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
                                                                                                 }
19

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.

20

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.