blaines_simplest_build.gradle
blaines_with_workarounds_build.gradle
build.gradle
error.zip
pom-default.xml
[GRADLE-1114] Cannot upload: POM does not validate Created: 13/Aug/10 Updated: 10/Feb/17 Resolved: 10/Feb/17 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 0.9 |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Robert Fischer | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 13 |
| Attachments: |
blaines_simplest_build.gradle
blaines_with_workarounds_build.gradle
build.gradle
error.zip
pom-default.xml
|
| Description |
|
I've got a pretty straightforward upload process, but it won't upload because the POM apparently won't validate. However, it seems valid to me, and it's generated pretty directly. I've attached the POM and the relevant files from the build directory. FAILURE: Build failed with an exception.
|
| Comments |
| Comment by Hans Dockter [ 16/Aug/10 ] |
|
The upload works for me if I use: repository(url: "file://localhost/tmp/robertRepo/") as a repository. Could you try this on your machine? One other thing I need to do differently was to use: compile files("/Users/hans/Downloads/cojen-2.2.1.jar", "/Users/hans/Downloads/trove-2.1.0a2/lib/trove-2.1.0a2.jar"), as they were not available from the defined repos. For some reason I can't get a local ssh upload working to check if wagon-ssh is the culprit. |
| Comment by lucas gray [ 25/Feb/11 ] |
|
I'm having the same issues, and I've narrowed it down to this: trying to deploy (ftp for me) to my local repository fails in this fashion when my project has dependencies that exist in the repository I'm publishing to. Unsure if the problem is simply because they're not in central, or if the problem is because of the 'circular-ness' of publishing to a repo that the dependencies come from. |
| Comment by Blaine Simpson [ 16/Oct/11 ] |
|
I am having this problem, and it persists after narrowing the test case drastically and eliminating the issues mentioned by Hans and Lucas about dependency availability and remote transfer protocols. My test case is a simple, non-nested project using only the Java and Maven plugins, attempting to publish to a local file repository, and it works perfectly well other than the Maven plugin features. I don't know of a more simple way to try to do what the Maven Plugin chapter of the user guide says to do, and it totally is not working. Attachment descriptions:
Update: Seems that a cache (I think the $HOME/.gradle one) was retaining some bad configs from an earlier attempt, because after wiping $HOME/.gradle and the project cache, uploadArchives is now working for me. _ |
| Comment by Stanford S. Guillory [ 20/Aug/12 ] |
|
I am experiencing the exact same symptoms when trying do deploy my artifacts to a Sonatype Nexus instance. Are there any plans to work on this defect in the near future? Thx |
| Comment by Nick Spor [ 29/Aug/12 ] |
|
Hi, if you have any dependencies like this: testRuntime group: 'junit', name: 'junit', version: '4.8' ive found that it will throw this error, after removing these dependencies from the task that was calling uploadArchives the pom validated and the war/pom would upload successfully. |
| Comment by Erich Oswald [ 04/Oct/12 ] |
|
I got the same error when I tried to publish a project that included a dependency to a JAR file in a flatDir repository. In the generated POM the groupId and version for that dependency were missing (well, can hardly blame Gradle for that Wouldn't it make sense if Gradle either ignored such incomplete dependencies when generating the pom-default.xml or at least gave a warning that it had to generate incomplete dependencies and the upload might fail? |
| Comment by Andreas Tschabuschnig [ 29/Aug/13 ] |
|
Still affected in 1.7 using plugin "maven-publish". Task "generatePomFileForMavenJarPublication" will create pom-default.xml without version information for external dependencies, whenever a dependencies version is set dynamically. Below code illustrates how I (used to) set the version for dependencies. The problem solved itself once I made sure each dependency is added including the version information. allprojects {
configurations.all {
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
if (!details.requested.version) {
def defaultVersion = getVersionFor(details)
if (!defaultVersion) {
if (details.requested.group.startsWith('com.mycompany')) {
defaultVersion = project.version
}
else {
throw new NullPointerException("no version defined for " + details.requested)
}
}
logger.debug ("Using version '${defaultVersion}' for ${details.requested}")
details.useVersion(defaultVersion)
}
}
}
}
|
| 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:
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. |
). When I moved the dependency to our local Maven proxy, publishing worked.