Gradle gives no clue about the error "Failed to validate POM for project" when doing a gradle install

(Jeroen Lankheet) #1

Hi people,

I’m a die hard maven guy, but a rookie on Gradle. I want to deploy my artifacts to a local maven repository but ran into problems. I did a gradle build install Wat it said: “Failed to validate POM for project”.

So I added the option --debug --stacktrace and tried other options. But all it said was: “Failed to validate POM for project” with a non conclusive stacktrace. Because I’m quite hard to beat, I copied the pom-default.xml to pom.xml on the project path and did a mvn install. Then I saw that there were spaces in the names of the artifacts. Bad me! Question is. How can I get those nifty maven messages from Gradle?

Thanks, Jeroen.

(Peter Niederwieser) #2

Can you show the full stack trace, preferably as a Github Gist?

(Jeroen Lankheet) #3

I don’t think the stack trace is very important here. The main idea is to get ‘all’ mvn output in the Gradle console as well. That should be doable, right?

(rupert THURNER) #4

we get this or a similar error. we have a gradle plugin, which should install in a maven repository. the plugin depends on jar files on the file system. so we do

repositories {

flatDir dirs: [‘mydir’] }

dependencies {

compile name: ‘lib-from-flatdir’

… }

when we want to install the plugin in a maven local repository a pom is generated which does not contain a version and a group. the install then fails with: Unable to initialize POM pom-default.xml: Failed to validate POM for project

i guess it should not try to include flatfile dependencies in the pom for deployment.

(rupert THURNER) #5

what else is kind of not-nice, that one cannot use an existing (class)path variable like a flatdir to express a dependency. something like

repositories { pathDeps path }

(Luke Daley) #6

We need the stacktrace to see where abouts in Gradle this is coming from.

(rupert THURNER) #7

luke, i’d really would have expected gradle would fix the underlying problem and not create an incorrect pom, and afterwards complaining that it is incorrect.

(Alex Antonov) #8

For me the problem was the use of quotes in the group property inside When the quotes were removed around the group id, everything worked! => works group=“” => breaks!!!

(Peter Niederwieser) #9

‘’ is a plain Java properties files, so in the second case you’ll end up with a group value containing quotes.

(Alex Antonov) #10

And that is precisely what breaks the POM validation. Remove the double quotes, and you get the correct POM :slight_smile:

(rupert THURNER) #11

one case yes. but the implementation of gradle is broken. it first constructs invalid pom files out of dependencies without version string, like "compile name: ‘lib-from-flatdir’ " and then complains about the file which it generated itself. and this with a cryptic error message. imo not acceptable behaviour.

(Davide Cavestro) #12

We are struggling on a similar issue… uploading fails with gradle 1.5, 1.6 and 1.7 but the pom seems ok at first sight.

The build always fails when uploading the jar for war subprojects, both using the original publishing mechanism and the new maven-publish plugin. I’ve shared a gist with the stack trace.

Follows an excerpt of our last attempt of configuring the upload for subprojects

  subprojects {subprj->

configurations {




batchConfig jar



repositories {

mavenDeployer {

repository(url: “file:///tmp/m2/”)




rootProject.uploadBatchConfig.dependsOn subprj.uploadBatchConfig }

It could be my fault (the multiproject build is quite complex) but without further details on the validation failure cause, I have no chances to fix it.

(Andrea Schiona) #13

Hi guys,

I’ve this problem too in using maven-publish plugin.

Any idea of the cause?

Thanks, Andrea

(Davide Cavestro) #14

For other folks’ convenience, please note that my issue had further refinements at