What is simplest uploadArchives setup that will actually work, using only Java and Maven plugins?

Need help getting uploadArchives working, using simplest Java plugin setup possible.

My first, simple goal is just to get uploadArchives to work for my sample Java project, which I purposefully made to be as simple as possible for educational purposes. Understanding that (other than uploadArchive/POM stuff) my Java project works perfectly well, including building the jar and running the generated program from it, very little from the Maven Plugin chapter of the user guide actually works, even when copy and pasting sample code. Most critically, I have never had uploadArchives complete because it ALWAYS aborts with:

Cause: Unable to initialize POM pom-default.xml: Failed to validate POM for project grpId:gramvn at /home/blaine/tmp/gramvn/build/poms/pom-default.xml

I understand that Gradle uses the Maven Ivy tasks underneath, but what a piece-of-crap validator that gives you no clue about what specifically failed to validate, even when run with debug logging? Since Gradle is generating this POM, implicitly, you would think it would generate the POM in such a form as to satisfy the validator that it is immediately going to run on it. This happens when I set no modifications, to use all defaults, and I have had no success by adding POM settings (from user guide and other configurations found on Internet) in an attempt to force Gradle to write a POM more palatable to itself.

My problem is pretty much GRADLE-1114, except that the Comments in that issue do not apply to me (using milestone 3).

I am only referencing dependencies which are available and I am attempting to publish to a local repository, and these are the only things that Hans and Lucas have any problem with. Note that my setup is more simple than the test case supplied in this Issue because mine is a simple top-level project with no nesting/sub-projects.

Since the validator gives no useful information, I don’t know if the validation is failing because of the missing “packaging” element, as described in GRADLE-1200. In the case of GRADLE-1200 the author is generating the POM explicitly, not implicitly by uploadArchives, but both his and my (implicitly generated) output POM files lack the packaging element. Unfortunately, I don’t know if lack of “packaging” results in the Gradle validation failure since the issue author says nothing about that. Could be that Gradle is satisfied with it but the Sonatype or whatever server doesn’t like Gradle’s POM. I have tried the total hack of a work-around for GRADLE-1200 at http://www.mail-archive.com/user@gradle.codehaus.org/msg05389.html , but copy and pasting the relevant code doesn’t add to the implicitly-generated POM at all. Therefore, I know of no way to get the packaging element inserted into the POM to eliminate that as possible cause of validation failure. (I also see that the explicit POM creation, done by copy and pasting the writeNewPom example from the user guide, also gets no packaging element). Maybe the packaging element is just a huge red herring, but what else…???

The related problems that I see discussed are related to nested projects, Sonatype, or Artifactory, but as I said, my setup is extremely simple: I am using only Java and Maven plugins and am just trying to publish to a local file repository.

I do have a build.gradle that includes all of the attempted fixes and configurations that I have found in forums, Jira, and user guide, but to keep this post short I’ll post here just my basic build.gradle which I have attempted to construct as instructed in the Maven Plugin chapter of the user guide:

apply plugin: 'java'
apply plugin: 'maven'
defaultTasks 'run'
repositories {
    mavenCentral()
    flatDir dirs: (
            new File(System.properties['user.home'], 'webapp-base/local/repos'))
}
dependencies {
    compile(
        [group: 'commons-logging', name: 'commons-logging', version: '1.1.1']
    ) { transitive = false }
    runtime(
        [group: 'commons-logging', name: 'commons-logging', version: '1.1.1'],
        [name: 'org.springframework.core', version: '3.1.0.M1']
    //) { transitive = false }
 Why the hell doesn't this work?
    )
}
  task(rtjars, type: Copy).from(configurations.runtime.files).into(libsDir)
  task setman (dependsOn: rtjars) << {
    println '================================'
    def deplibs = []
    configurations.runtime.files.collect { deplibs << it.name }
    println 'DEPLIBS: ' + deplibs.join(' ')
    jar { manifest {
        attributes( 'main-class': 'pkga.Main',
        'class-path': deplibs.join(' ')
    ) } }
}
  jar.dependsOn << setman
  task run (dependsOn: assemble) << {
    println configurations.runtime.files
    javaexec { main = '-jar'; args = [jar.archivePath, 'par1', 'par2'] }
}
  uploadArchives {
    repositories.mavenDeployer {
        repository(url: "file://tmp/fake-repos/")
    }
}
  // Required by uploadArchives:
group = 'grpId'
organization = 'Me'

I see that this forum totally butchered my post around a JIRA issue reference and URL to a workaround on the gradle-user mailing list. If a reader can’t figure out the intention, let me know and I’ll see if I can re-write that part to satisfy the forum parser. Sure wish I had the ability to edit my own previous posts here.

Hi,

The error messages aren’t very helpful. But try adding a version property for your project: version=‘1.0’

(maven layout pretty much expects

artifactId -> default (project.)name

groupId -> group

version -> version

also I had to change your url to file://localhost/tmp/fake-repos/ (first part being host)

other than that it works fine for me.

cheers Magnus

Thanks Magnus, but I made both changes, as you can see below, and nothing changed??? I had tried adding version before, and though that does cause the version element to be written to the generated POM file, it has no effect on the validation failure.

apply plugin: 'java'
apply plugin: 'maven'
defaultTasks 'run'
repositories {
    mavenCentral()
    flatDir dirs: (
            new File(System.properties['user.home'], 'webapp-base/local/repos'))
}
dependencies {
    compile(
        [group: 'commons-logging', name: 'commons-logging', version: '1.1.1']
    ) { transitive = false }
    runtime(
        [group: 'commons-logging', name: 'commons-logging', version: '1.1.1'],
        [name: 'org.springframework.core', version: '3.1.0.M1']
    //) { transitive = false }
 Why the hell doesn't this work?
    )
}
  task(rtjars, type: Copy).from(configurations.runtime.files).into(libsDir)
  task setman (dependsOn: rtjars) << {
    println '================================'
    def deplibs = []
    configurations.runtime.files.collect { deplibs << it.name }
    println 'DEPLIBS: ' + deplibs.join(' ')
    jar { manifest {
        attributes( 'main-class': 'pkga.Main',
        'class-path': deplibs.join(' ')
    ) } }
}
  jar.dependsOn << setman
  task run (dependsOn: assemble) << {
    println configurations.runtime.files
    javaexec { main = '-jar'; args = [jar.archivePath, 'par1', 'par2'] }
}
  uploadArchives {
    repositories.mavenDeployer {
        repository(url: "file://localhost/tmp/fake-repos/")
        //repository(url: "file://tmp/fake-repos/")
    }
}
  // Required by uploadArchives:
group = 'grpId'
organization = 'Me'
version = '1.0'

Hmmm… maybe something todo with your dependencies then.

q1) Why commons-logging in both compile and runtime scope ? Runtime inherits from compile. q2) Your spring dependency looks suspicious. (no group given). Is that on purpose ?

out of curiosity whats in yout flatDir repo ? Are any of your input dependencies kept there ? (for this sample ?)

-magnus

FYI

copied your script.

Added

  • mavenRepo urls:“http://maven.springframework.org/milestone” to the repositories section and

  • changed spring dependency to : group: ‘org.springframework’, name: ‘spring-core’, version: ‘3.1.0.M1’

and it ran fine for me.

Sorry. I answered one queston wrong and have been trying to correct this post since, but my browser frooze up.

Answers.

q1) I think that was left-over from a previous test case where I was debugging problems with dependency bleed-over. Unrlated to current problem and I very much doubt redundant dependencies are effecting the problem at-hand, but I’m removing the redundant runtime dep now.

q2) Yes. For dependency reading purposes (i.e. the repository used only for reading), the flatFile purposefully contains only jar files in a single directory, knowingly not supporting conflicting jar file names, and therefore specifying group would add no benefit and lead to false confidence. I’ve done this in hundreds of ivy.xml files and it works fine. Of course things are totaly different on my pushlishing side here, since I am trying to publish to Maven layout.

Unnumbered q) I figured that the source project that I started this test case from used something from the flatDir repo, but it does not. I had to override several Spring jars because at that time the versions I needed were not in the Maven repos. I used my flatDir repos for the purpose of providing jar files not available in Maven repository. However, though that justified it in the original project (used as starting point for this test case), I certainly should not have introduced that unnecessary complication here. I’ll remove it.

I have eliminated the 2 ambiguities that you just mentioned (by removing the flatDirs definition and the 2nd commons-logging dep), and the situation remains exactly as it was. All targets work perfectly except that uploadArchives fails as described. Update: Must be cached somewhere because, as you note in following post, the Spring jar can only be resolved as specified in my local repos… yet things continue to run as before after removing the repos. Instead of cleaning caches, I’ll just remove the spring dependency, which is unnecessary.

(Sure wish this forum let you preview entries before posting. Any system that lets you write markup should let you preview the effects of it first, especially when the submittals all get broadcasted.)

Re: Magnus “FYI” entry:

I did just what you said you did, after disabling redundant commons-logging dep and flatDir repos, as pasted immediately herafter. No effect. After that, I just eliminated the whole Spring dependency issue by eliminating it (since it’s not really needed by the app) by commenting out the dependency specification for it in the build file below. At this point I have an extremely stripped down test case (37 non-empty non-comment lines, including print statements) and I am still getting the validation error…

apply plugin: 'java'
apply plugin: 'maven'
defaultTasks 'run'
repositories {
    mavenCentral(urls: 'http://maven.springframework.org/milestone')
    //flatDir dirs: (
            //new File(System.properties['user.home'], 'webapp-base/local/repos'))
}
dependencies {
    compile(
        [group: 'commons-logging', name: 'commons-logging', version: '1.1.1']
    ) { transitive = false }
    runtime(
        //[group: 'commons-logging', name: 'commons-logging', version: '1.1.1'],
        [name: 'spring-core', group: 'org.springframework', version: '3.1.0.M1']
        //[name: 'org.springframework.core', version: '3.1.0.M1']
    //) { transitive = false }
 Why the hell doesn't this work?
    )
}
  task(rtjars, type: Copy).from(configurations.runtime.files).into(libsDir)
  task setman (dependsOn: rtjars) << {
    println '================================'
    def deplibs = []
    configurations.runtime.files.collect { deplibs << it.name }
    println 'DEPLIBS: ' + deplibs.join(' ')
    jar { manifest {
        attributes( 'main-class': 'pkga.Main',
        'class-path': deplibs.join(' ')
    ) } }
}
  jar.dependsOn << setman
  task run (dependsOn: assemble) << {
    println configurations.runtime.files
    javaexec { main = '-jar'; args = [jar.archivePath, 'par1', 'par2'] }
}
  uploadArchives {
    repositories.mavenDeployer {
        repository(url: "file://localhost/tmp/fake-repos/")
        //repository(url: "file://tmp/fake-repos/")
    }
}
  // Required by uploadArchives:
group = 'grpId'
organization = 'Me'
version = '1.0'

I’m baffled :slight_smile:

Got your script above to run with both milestone-3 and milestone-5 snapshot 13.oct.

Running out of ideas… maybe try wiping your gradle cache (and any .gradle folder in your project) ?

This really should be plain sailing so I completely understand your frustration.

cheers Magnus

Thanks for understanding my frustration, Magnus.

I can’t do anything on it now, because I’m at my day job, but in about 6 hours from now I will

  1. Clear all caches on my workstation and retry. If that doesn't work...
  2. Zip up the complete (other than being "cleaned") project and try it on a very clean PC (no Ant or developer tools other than Java SDK) that I use for this purpose, and if I can reproduce problem there then...
  3. Post my project .zip to GRADLE-1114. Hopefully somebody smart like Magnus can elicit the problem and narrow down what in my project is bad.

Working now!

After wiping both project caches and $HOME/.gradle, it worked. I had wired the project cache before but I thought that $HOME/.gradle would be used so as not to set problems into cement-- but I guess not.

Thanks for your patience, Magnus.

For me the problem was the use of quotes in the group property inside gradle.properties. When the quotes were removed around the group id, everything worked!