I am trying to publish an RPM artifact from our project into a Yum Repo on Nexus via Gradle:
publishing {
repositories {
ivy {
url 'http://myrepo:8081/repository/myproject'
credentials {
username "aaa"
password "xxx"
}
layout "pattern", {
artifact "${buildRpm.outputs.getFiles().getSingleFile().getName()}"
}
}
publications {
rpm(IvyPublication) {
artifact buildRpm.outputs.getFiles().getSingleFile()
}
}
}
}
When I run ./gradlew publish this task gets picked up and starts to upload the main .rpm artifact of 90MB. It then fails after this with the following error:
> Task :search:publishRpmPublicationToIvyRepository FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':search:publishRpmPublicationToIvyRepository'.
> Failed to publish publication 'rpm' to repository 'ivy'
> Could not write to resource 'http://myrepo/repository/myproject/myproject-1.23.4.noarch.rpm.sha1'.
> Could not PUT 'http://myrepo/repository/myproject/myproject-1.23.4.noarch.rpm.sha1'. Received status code 400 from server: Invalid path for a Yum repository
How can I prevent the .sha1 file to be uploaded? I only want the RPM to be uploaded (which is apparently the only thing allowed on this repo).
I also tried using maven-publish instead of ivy-publish but both give similar issues. maven-publish tries to upload a .pom with a similar failure.
I am able to upload the RPM fine manually using curl, but I would rather do it using Gradle plugins and standards.
Related
I have a project using gradle from building and due to some recent jcenter issues, we want to move all our dependencies to our artifactory. Now i have all the configuration ready and declared inside the gradle build files. I have also removed all traces of other maven repositories.
repositories {
maven {
url "${artifactory_contextUrl}/repo_name-generic"
credentials {
username = "${artifactory_user}"
password = "${artifactory_password}"
}
}
}
After doing a gradle clean build, i expected a lot of errors as i have never added those dependencies to our artifactory repo, but none came. The project builds fine and i can see them being downloaded.
My question now is, why is it working?
Is there a way i can check from which source the dependencies are coming from?
Also in artifactories GUI i cannot locate the packages inside the specified repo
Thanks!
If you ant to print the repositories a project is using, the following task will do it for you:
task printRepos {
doFirst {
project.repositories { repositories ->
repositories.forEach { repo ->
println("${repo.name}: ${repo.url}")
}
}
}
}
If you add it to your gradle build and invoke it gradle printRepos, you should get the repositories printed out
For more information regarding the API, check: https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/dsl/RepositoryHandler.html
https://docs.gradle.org/current/javadoc/org/gradle/api/Project.html
Also thanks to Bjorn for pointing out the doFirst/doLast problem.
rm -rf ~/.gradle/caches
./gradlew assembleDebug -i > ~/Desktop/dump
search dependency lib in dump file to check where it was downloaded from
For example, flexbox-2.0.1 was downloaded from jcenter:
I would like to configure gradle with plugin for artifactory to push Android libraries. I don't have any issue with pushing aar files, but when pushing the POM I receive 409.
What went wrong: Execution failed for task ':artifactoryDeploy'.
java.io.IOException: Failed to deploy file. Status code: 409 Response message: Artifactory returned the following errors: The
target deployment path 'test/path.../0.0/name-0.0.pom' does not match
the POM's expected path prefix 'path.../0.0'
Current configuration:
artifactory {
contextUrl = "url"
publish {
repository {
// The Artifactory repository key to publish to
repoKey = 'test'
username = "test"
password = "test"
}
defaults {
publications('aar')
publishArtifacts = true
// Publish generated POM files to Artifactory (true by default)
}
}
}
I suppose there is an issue with adding repoKey before path. How can I force artifactory plugin to add repoKey ("test") before path?
I have a multi-project gradle (version 2.1!!) build consisting of non-java projects.
I would like to deploy the generated artifacts (.tar.gz files) to a Nexus and also to a directory.
Currently I define the repositories in the root build.gradle in the repositories block and also again for each sub-project in a repositories block inside the subprojects in the root build.gradle file.
I apply the base plugin to the root project and the maven-publish plugin to all subprojects that have artifacts to be deployed.
I tried to follow the instructions here:
https://docs.gradle.org/2.1/userguide/publishing_maven.html
https://docs.gradle.org/2.1/dsl/org.gradle.api.publish.maven.MavenPublication.html
https://discuss.gradle.org/t/how-to-have-multiple-uploadarchives/19381/3
How can I make uploadArchives dependent on another task?
and a few more...
but nothing worked. :-(
Here's what I do:
...
# apply the maven-publish plugin only to sub-projects that produce artifacts that should be uploaded.
apply plugin: 'maven-publish'
publishing {
publications {
tarFiles (MavenPublication) {
artifact compressTar
}
}
repositories {
add rootProject.repositories.fsShare
add rootProject.repositories.nexusDeploy
}
}
...
The compressTar is my custom Tar task that creates the artifacts that I want to upload.
When I execute ./gradlew publishTarFilesPublicationToNexusDeployRepository I get the following error:
Execution failed for task ':mySubProject:publishTarFilesPublicationToNexusDeployRepository'.
> Failed to publish publication 'tarFiles' to repository 'nexusDeploy'
> Failed to retrieve remote metadata myRootProject:mySubProject:0.0.0.0-SNAPSHOT/maven-metadata.xml: Could not transfer metadata myRootProject:mySubProject:0.0.0.0-SNAPSHOT/maven-metadata.xml from/to remote (https://myProject.nexus.url:443/nexus3/repository/builds/): Could not get resource 'myRootProject/mySubProject/0.0.0.0-SNAPSHOT/maven-metadata.xml'
When I execute uploadArchives, the task succeeds, but nothing is uploaded anywhere and from the output it looks like the uploadArchives task is only executed for sub-projects that didn't get the maven-plugin applied.
What is the right way to do this? Which plugins should I apply when/where?
Apparently there were two un-related "problems at work" here.
Problem 1): I was not able to publish to Nexus and got a Failed to retrieve remote metadata-error:
Answer 1): I was trying to publish a "SNAPSHOT" to a repository that was configured not to accept "SNAPSHOT" build. Renaming the build version from 1.2.3.4-SNAPSHOT to anything else (e.g. 1.2.3.4-SNAPSHOT-dev or more reasonable 1.2.3.build4`) worked fine.
Problem 2) Publishing to 'flatDir' repository didn't work. The maven-publish plugin didn't create the publish task for it.
Answer 2) To use maven-publish to publish to a directory, flatDir apparently is not recognized as repository the maven-publish plugin can publish to. Defining the 'directory' repository as follows worked fine:
maven {
name "fsShare"
url "/share/pkg"
}
I have some jar files in my local system which I wanted to publish using Gradle script but I could not find any solution till now.
I am able to publish artifacts which my build generates but I want to publish jars which are there in my local system.
I tried to declare the artifact something like following but it is throwing error:
publishing {
publications {
mavenJava(MavenPublication) {
artifact projJar
//This is jar file other than my built file which I want to upload (there are same files more in number to be uploaded):
artifact 'D:/myworkspace/Test/LocalJar.jar'
artifact source: projJar, classifier: 'src', extension: 'jar'
}
}
repositories {
maven {
credentials {
username 'user'
password 'password'
}
url "http://IP:Port/repository/RepoName/"
}
}
}
Error msg is:
*What went wrong:
Execution failed for task:publishMavenJavaPublicationToMaven2Repository'.
> Failed to publish publication 'mavenJava' to repository 'maven2'
> Invalid publication 'mavenJava': multiple artifacts with the identical extension and classifier ('jar', 'null').
Please guide me with some example how I can publish my local jar files to nexus repository (there are a lot of files there in my local which I want to publish)
My program outputs a zip and I want to deploy this zip to the nexus repository. I am using gradle as build system.
Fragment of my configuration:
class DestinationFileTask extends DefaultTask {
File destFile;
}
task generate(type: DestinationFileTask) {
destFile = file('output/file.zip')
}
artifacts {
output generate.destFile
}
uploadArchives {
repositories {
mavenDeployer {
repository(url: "url")
pom.version = "1.01-SNAPSHOT"
pom.artifactId = "ID"
pom.groupId = "com.test.test"
}
}
}
When I am executing gradle uploadArchives I am receiving this error:
> Could not publish configuration 'archives'
> A POM cannot have multiple artifacts with the same type and classifier. Already have MavenArtifact ID:zip:zip:null, trying to add MavenArtifact ID:zip:zip:null.
Even when I try to do this for the first time.
I ran into the same issue while working on Gradle upgrade:
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':registry:uploadArchives'.
> Could not publish configuration 'archives'
> A POM cannot have multiple artifacts with the same type and classifier. Already have MavenArtifact registry:zip:zip:null, trying to add MavenArtifact registry:zip:zip:null.
Gradle upgrade it self has nothing to do with the error its more related to the plugins you are using.
The error is really misleading and there is not much info on Google about it as well.
But it turns out that the cause of this error is Maven trying to upload artifact on top of the other one.
So first of all check what packaging tasks you are executing, in my case:
task ':registry:bootDistTar',
task ':registry:bootDistZip',
...
task ':registry:distTar',
task ':registry:distZip',
The workaround to fix it is to change the classifier (in my case for spring boot app):
bootDistTar {
classifier = 'bootTar'
}
bootDistZip {
classifier = 'bootZip'
}
Hope this will help for someone else as it was quite hard to figure out.
Github issue where I found the workaround.