I manually deploy(click button on web) FGE-0.3.zip to lib-release without a pom file. For some reason I check Suppress POM Consistency Checks of a lib-snapshots, and after that there are a lot of error messages in my system logs:
Sending HTTP error code 409: The repository 'lib-snapshots' rejected the artifact 'lib-snapshots:com/tools/FGE/0.3/FGE-0.3.pom' due to its snapshot/release handling policy
FGE is actually in a lib-release, why is this happen?
You are most probably trying to deploy a release artifact to a repository that you configured not to handle releases - the name of the repository by itself has no bearing on it's behavior so you probably mixed something up.
Repositories in Artifactory can handle release or snapshot artifacts or both - which artifact is considered release or snapshot is determined by the repository's layout (The folder and file integration revision parts in it specifically).
POM consistency checks are there to validate the path you deployed a pom file to adheres to it's GAV coordinates - the error you are seeing is because of the handle release \ handle snapshot configuration.
Related
I'd like to mvn deploy an artifact with the suffix -DEVELOP into the pre-defined snapshot repo, but maven decides to push it into the release repository. I guess it is due to naming policy, the artifact withouth -SNAPSHOT goes to the release repo.
But if I set the snapshot repo explicitly for this deploy job, I get a 400 Bad request error. Is it because the snapshop repo only permits artifacts with the snap suffix?
Thanks in advance!
During our intraday builds, we intermittently (perhaps twice a day) get a '401 Unauthorized' error when maven performs the 'deploy' step of the build. This error is seen on both the maven console and in the Artifactory requests.log. The time of day isn't consistent, nor is it tied to a snapshot/release repository. I've checked and doublechecked all security settings and urls, and since this error is intermittent, I'm confident the issue lies with Artifactory.
I also get this intermittently with a 'mvn deploy:deploy-file'. Today it failed on 1 upload out of approx 300.
I've raised a jira with Artifactory but it's not been picked up yet: https://www.jfrog.com/jira/browse/RTFACT-14982
I should add that we didn't encounter this issue when using Archiva as our repository. It's happened regularly since I migrated to Artifactory
With regards to the pom.xml example, the reason it is failing is that the deploy-file goal is missing the repositoryId property.
This property should include the repository id for the repository you use for deployment, for example:
<repositoryId>internal-snapshot-local</repositoryId>
The plugin will use this id for getting the deployer credentials from the Maven settings.xml file.
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'm trying to set up a release plugin in a maven project but it fails at deployment of release artifacts in release:perform. The Nexus repository returns 400 and the maven log tells me that the binary is installed twice to my local repo and then also attempted to be uploaded twice.
I get the feeling that it's related to a custom (3rd party) packaging I'm using - but due to business reason I cannot reveal the name of this.
Anyone that think of a "typical" packaging error that would fool maven to install and deploy the jar twice? other artifacts like javadocs, sources etc do not suffer the sample problem.
apparently my Nexus is rejecting every deploy I throw at him if the artifact has not -SNAPSHOT in the version.
Data:
name of the failing artifact: entando-core-engine-experiment-bundles_with_bootstrap.jar where experiment-bundles_with_bootstrap is the version as in the version element of the pom.xml
hosted repository policy on my Nexus: Snapshot, allow redeploy and so on (classic conf for snapshots)
deployer: Jenkins 1.481
same Jenkins job, but entando-core-engine-SNAPSHOT.jar ---> SUCCESS
I need this naming convention because I'm building one of the several experiments we run internally, as opposite to the canonical develop branch which produces a proper entando-core-engine-SNAPSHOT.jar
Any advice?
I'm totally lost.
The thing is that usually your Nexus is configured not to allow a redeployment of a release. A release from Maven point of view is an artifact where it's version it NOT -SNAPSHOT. In contradiction a SNAPSHOT is intended to be deployed several times into nexus.
This sounds like you don't using the release plugin of Maven nor the Release PLugin of Jenkins.
Nexus is a repository manager that uses different repository formats, with the main format being the Maven repository format. Changing the names of artifacts on the server is not possible since it violates the format. They have to be located in the directory structure established by groupId, artifactId and version and use the artifactId-version-classifier.packaging for the file names.
If you need a different file name on the server you have to look at a different repository format (bad idea). If you need the filename on the client just download from the correct name and rename..