I am trying to setup the https://repo.grails.org/core repository as a remote repository on my artifactory instance. If I use that URL directly in the configuration, I can pull everything except the maven-metadata.xml. Maven will throw an error saying it got a 404 for it, and I can verify that by trying to manually pull it through my remote repo.
I have also tried setting up the remote as a smart remote, entering just https://repo.grails.org/artifactory. It will recognize it as an artifactory server, but if I hit Test I get a 500 error. Saving the settings the repo shows no artifacts.
I have also tried https://repo.grails.org/artifactory/core, /artifactory/api/core, /artifactory/api/maven/core, /grails/core as well as a few others and those that work for retrieving jar or pom files still give a 404 for the maven-metadata.xml.
What is the correct way to configure the repo.grails.org repo as a remote repository?
I have tried this is both the 7.29 and 7.3 versions of artifactory with the same result.
From our previous experience, it was understood that grails repository core that you are pointing to is a virtual repository. grails admins might have added all the remote and local repositories under this. But artifactory does not support virtual repositories for smart remote repositories. You may need to point to the correct path.
You may try to point to https://repo.grails.org/core and then can you share the full path of the file that you are trying to download and facing the issues right now.
Related
I want to simply download a war file from a Nexus repo and deploy it on a remote tomcat server.
I found this plugin https://wiki.jenkins.io/display/JENKINS/Repository+Connector+Plugin, which seems to help me do the same.
I have the following configuration:
In hue-central, I have correctly configured the repo url.
If I open <repo url>/com/worksap/company/hue-interface-front in my browser, I can see all the versions along with maven-metadata.xml, which contains all the versions.
Am I missing something?
Try following: Go to Jenkins Administration / System configuration, find the Artifact Resolver section, and check Repo Type of your repository. If it is empty, set it to "default". It was causing the same problem in my case.
Example here.
The internal repo suddenly gave up. All the artifacts are there and can be browsed through the browser but if you actually click on an artifact or a pom to download it it hangs.
Jenkins uses Archiva as well and suddenly can no longer fetch new artifacts from the internal repo. All we get is this 500 error: 500 , ReasonPhrase:Unable to fetch artifact resource
The internal repo mirrors maven central.
Any ideas?
Perhaps you're out of hard drive space or your server's internet connection to the outside isn't operational?
A restart of Archiva may do the trick if not.
I'm using Grails 2.4.1 & The Grails Release plugin version 3.0.1.
I have a Sonatype nexus repository (v2.3.1-01) setup that's in use by several other projects with no issues.
I'm attempting to create a new Plugin that I want to distribute through a SNAPSHOT repository in nexus (and later through our Releases repository).
In my ${projectName}GrailsPlugin.groovy file I have:
def groupId ="my-department-grails-plugins"
def version = "0.1-SNAPSHOT"
In my application.properties file I have:
app.name=MyPluginNameForGrails
In my BuildConfig.groovy I have:
grails.project.repos.newsnapshots.url = "http://internal.server.address/nexus/service/local/repositories/snapshots"
grails.project.repos.newsnapshots.username = "username"
grails.project.repos.newsnapshots.password = "password"
I'm trying to kick things off with the following command:
publish-plugin --snapshot --repository=newsnapshots --stacktrace
The build success everything looks good until it trys to push into nexus and I get:
Using configured username and password from
grails.project.repos.newsnapshots ....Error | Failed to publish
plugin: Error deploying artifact
'ald-grails-plugins:my-plugin-name-for-grails:zip': Error deploying
artifact: Failed to transfer file:
http://internal.server.address/nexus/content/groups/public/my-department-grails-plugins/my-plugin-name-for-grails/0.1-SNAPSHOT/my-plugin-name-for-grails-0.1-20140815.191240-1.zip.
Return code is: 400
I've found a related StackOverflow question which seems related but none of the conditions they describe as causing the 400 exist.
I also found the article by Sonatype Nexus which describes possible causes of 400's and those don't seem to be it either.
If you notice the repository that I'm pointing to, it is directly to a repository but then in the error message it lists a path to a group. I am thinking this may be somehow related but but if so... I am not sure how to fix it since this seems to be happening somehow internal to the Releases Plugin.
I should also add that I've removed the -SNAPSHOT from the GrailsPlugin.groovy file and changed the destination repository to be our RELEASES repository with the exact same result.
My problem was due to a mirror defined in my .m2/settings.xml file (thanks Jeff Beck for the comment that led to the resolution!). This was causing the POST to the repository to be redirected to the public GROUP which wasn't allowing the artifact to be uploaded.
There are a few other secondary causes that were contributing to my troubleshooting issues:
While uploading to a SNAPSHOT repository your version number must
be of the pattern x-SNAPSHOT where x can be anything(?).
You cannot upload to a SNAPSHOT repository when using the Nexus ReST
API. This didn't actually end up affecting my specific solution but
it's worth noting for others that may run into this issue.
While uploading to a NON-SNAPSHOT repository your version number must NOT
be of the pattern x-SNAPSHOT.
Given a mirror setting in the .m2 directory the grails release plugin will have issues trying to deploy xif the mirror matches where you are deploying to. You can remove the mirror setting or change it to not match your targeted repo. Check out these jiras for more info:
GPRELEASE-7
GPMAVENPUBLISHER-3
I inherited this project which used to build & run successfully (years ago...). Now when checked out from version control, as is, it complains:
Unable to find resource 'opensymphony:quartz-all:pom:1.6.3' in
repository central (http://repo1.maven.org/maven2)
But following that repository link (http://repo1.maven.org/maven2) leads to a browsable site that shows clearly that this resource is available: http://search.maven.org/#browse|1030701351 !
I have even been able to manually download it, and I can also find it in my local repo (C:\maven\repo\opensymphony\quartz-all\1.6.3\quartz-all-1.6.3).
So, my questions:
Why is Maven complaining at all, if it is there?
How did it get to my local repo, if Maven couldn't find it?
Your local repository is NOT in C:\maven ... it is in your users directory ~/.m2/repository
To debug what is really going on I would suggest to deactivate the ~/.m2/settings.xml (e.g. by renaming it) and do a clean build without any of the old artifacts and from a fresh local repository (just delete ~/.m2/repository)
That would tell you what is really missing.
If anything is missing that means it is not in the Centra Repository (http://search.maven.org). As a next step I would then install a repository manager in your network. I would recommend using Sonatype Nexus (open source, free book as documentation) and then add any other repositories or missing artifacts in there.
I am working on a large project with remote private repository.
Someone set one of the reposirories as http://central
And on every child's module build maven tries to download from this repo.
(I dont have any access to it)
Now I am getting this error
Could not transfer metadata com.company.project:child-lib-ui:01.111.00.00-SNAPSHOT/maven-metadata.xml from/to central (http://central): Error transferring file: Server returned HTTP response code: 503 for URL: http://central/
A have already deleted all mentioned "http://central" from all pom's, cleared all local repository, but now Im still getting this repo in build.
What can I do to skip this repo?
Probably you have this repo declaration in your settings.xml file.