Why do I get a 400 when attempting to use publish-plugin from the Grails Release plugin - maven

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

Related

AEM Mocks missing artifact for latest version

I have added the latest version of AEM Mocks (2.7.2) as a Maven dependency in my AEM project. When I try to build my project, I get an error saying that this artifact cannot be found: com.day.commons:day-commons-gfx:jar:2.1.28. So I looked online, found it and added it as a dependency. But now I get the same error when trying to build. Does this artifact still exist? When trying various recent versions of AEM Mocks, I found that they all depend on this missing artifact.
For now, I downgraded to version 2.3.0, which works fine without that artifact but I would like to use the most recent version if possible.
Can anyone please help? Thanks!
This artifact is defined as a workaround, it is explained here in comment:
https://github.com/wcm-io/wcm-io-testing/blob/develop/aem-mock/core/pom.xml#L254:
Workaround for AEM 6.5: The new uber-jar does no longer contain the package com.day.imageio.plugins
It works without any issues for me, so I would check if you have correctly configured Maven repositories. To do it, in your Maven project root type:
mvn help:evaluate
and then:
${project.repositories}
It should list your project effective repositories. Ensure that there is Central Repository (https://repo.maven.apache.org/maven2/) listed. If it is there, then maybe your corporate network cuts requests to external repositories or it was temporarily down.

Intermittent 401 error from Artifactory when deploying files

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.

No versions could be resolved for groupid.artifactid error when using Repository Connector

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.

Maven Error: No plugin found for prefix ‘archetype’ in the current project using Nexus

I am trying to setup MAVEN in my company's local network which is not connected to the internet directly. Also I'm using sonatype nexus for my central repository.
Problem starts when I run the command mvn archetype:create. The result is always build failure.
error no plugin found for prefix 'archetype' in the current project.
How do I solve this issue?
Maven is trying to look up the full plugin artifact ID that corresponds the "archetype" prefix.
To do this it reads the available prefixes from this path: /org/apache/maven/plugins/maven-metadata.xml
Since you're using Nexus this is likely coming from a group repository, e.g.:
http://:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-metadata.xml
You'll need to look carefully at your maven configuration and your build log to see where exactly it is trying to retrieve this information. There will likely be additional information about the failure if you run Maven with the debug ("-X") flag.
If it's trying to retrieve it from your Nexus instance see here for information on how to diagnose the issue:
https://support.sonatype.com/entries/21437881

deploy on nexus artifacts with Snapshot policy but without SNAPSHOT string in version

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..

Resources