Secondary Jar version don't sync up when deploying - gradle

I'm using gradle artifactory plugin to deploy my library to oss-snapshot-local.
The first deploy works as intended and the filenames are correct:
eg.
skrypton-api-1.0.0-20171014.053125-1-sources.jar
skrypton-api-1.0.0-20171014.053125-1.jar
But on the second deploy, the sources jar is not uploaded despite the plugin saying it has deployed it. I end up with only
skrypton-api-1.0.0-20171014.053349-2.jar
Deploying for the third time,
skrypton-api-1.0.0-20171014.053349-2-sources.jar shows up. But not third source jar. Only skrypton-api-1.0.0-20171014.054252-3.jar
This is what it looks like in general after 3 deploys
The source jar version seems to be stuck at (deploy number - 1) after the first deployment. Tried it with a javadoc jar and it also doesn't work properly.
This is the build script in question.

Related

Maven - Jenkins issue

There are couple of issues I am facing in Jenkins integration . I run the scripts from local Eclipse and it works perfectly fine with Selenium Grid. I am trying to setup this whole thing in Jenkins and facing the following issues
1. cannot find symbol - Seeing this issue in Jenkins and searched about this in Stack Overflow . Verified the JDK version and my pom.xml version matches with the one installed in Jenkins.
2.I have three packages- One has the framework , second one has the main method and the third one has the code related to the application i am testing. I am converting my framework to a jar and uploading the entire thing to GIT . When i build the project jar using Maven install , its not including the framework jar which is causing the issue . I tried a lot of things suggested in Stack Overflow and it did not work. I am quite new to this kind of Maven stuff
3. I am not even able to run the scripts with the help of the runnable jar in my local because of issue# 2
Some of these have already been posted but i tried out those things and did not work for me or I might be missing something
In Maven you have a file called settings.xml which contains URL of the location from where you want to fetch all your dependencies like here JAR files in your case from GIT. It works from your eclipse because maven looks for dependencies in your .m2 folder which are there when you run it from eclipse. But, in order to build it from anywhere else you need to specify that URL in maven's settings.xml

How to stop maven deploying test jar files

Maven has a useful facility to create jar files for tests that can be depended on by other projects. We use the "easy way" from this page. This all works fine, and produces files of the name foo-1.0.0-tests.jar.
By default, these test jar files are installed and deployed. The question is how to have them be installed, but NOT deployed?
(There is no need or desire to publish these files to maven central, but they are needed when running tests locally. Thus install is correct, and deploy is not.)
The maven deploy plugin appears to have has no suitable options. The build-helper-plugin has the ability to attach file to deploy, but not to remove them.
Any suggestions to get these jar files installed, but not deployed?

Can not deploy from maven after deploying using CLI on JBOSS

On our jenkins we have a build pipe that as a last step deploys the artifact (ear file in this case) to a remote JBoss 6.4 server. This works fine as long as I don't install that same ear file using tje JBoss cli on the server. After that Maven complains:
Failed to execute goal org.jboss.as.plugins:jboss-as-maven-
plugin:7.7.Final:deploy (deploy) on project caretrack-ear:
Deployment failed and was rolled back. "JBAS018785: There is
already a deployment called foo-ear-1.0-SNAPSHOT.ear with the
same runtime name foo.ear"
Found the problem.
Apparently as we build the assembly, used with the manual deploy, the ear file has a different name than the ear file built in the continuous integration pipe. Both try to deploy, different name but same runtime name.
The ear in the Assembly contained an ear with the version number still attached, while the ear in the ci-pipe had it's version number stripped.

Grails Release Plugin Maven Deployment doesn't update <latest> tag in maven-metadata.xml consistently

Background
I have two Grails applications, both running Grails 2.3.6 with the release plugin installed (build ":release:3.0.1").
I have a jenkins CI server setup to automatically pull the projects from source control and deploy the war to artifactory. From there, it can be automatically deployed to our tomcat server by a script.
For one application, the maven-metadata.xml file generated by Artifactory contains a <latest> tag, which specifies which of the versions of my application is the latest one.
Problem
My problem is, the other application doesn't have a <latest> tag, even though it's using the exact same command to deploy to our Artifactory repository-- grails maven-deploy. The BuildConfig.groovy files are basically identical.
This is a problem because I need that <latest> information to be available for my deployment script.
From what I've read around the web, the maven-metadata.xml file is generated by maven 2 only when the -DupdateReleaseInfo=true flag is set. However, I can't see any place that the working application is passing this flag to maven during the build.
I've tried the fix suggested on this thread-- namely,
Making sure that deploying user has "annotate" permission
Maven Snapshot Version Behavior = "Deployer"
But my second application still doesn't get a <latest> tag added to its maven-metadata.xml.
So, I figured out that I can easily just pass -DupdateReleaseInfo=true to the grails maven-deploy command as an additional argument, and that forces maven to update the <latest> tag in maven-metadata.xml. I'm not sure why it is doing it sometimes and not others, but at least it works!

Jenkins: deploying war files from artifactory

We are using Jenkins to build (maven) & deploy artifacts (JARs & *WAR*s) to an in-house artifactory server (both snapshots and releases).
For deployment, currently, we got Jenkins jobs that package the war file (from a release scm tag) and deploy to different environments/servers. We want to skip the package phase as it seems unnecessary to package it again & again for a released version because it's not possible to get a different copy of war file even after trying 1000 times.
We are looking for a way in Jenkins to get the artifact (war) from Artifactory and deploy it to a container. I am sure other people would have faced this situation too but I am not able to find any online material regarding this.
Is there any Jenkins plugin that takes a war file from Artifactory (based on a version) and deploy it to a remote container?
If this is not the right way of doing it then what are the recommendations for any other approach?
Thanks
I don't know about a plugin which takes a version # and deploys that, but you can build a Jenkins job to deploy the last successful release to a previous environment (thus copying from DEV-->QA for example.)
To do this, you would use the copy-artifact-plugin.
Here's an easy to follow run-through of this kind of setup:
http://www.lordofthejars.com/2012/09/deploying-jee-artifacts-with-jenkins.html
Every artifact stored in Artifactory will have a unique URL that includes the version number. It will take the format
http://artifactory-server/repository-name/path-to-artifact/version/filename
e.g.
http://artifactory/apps-releases-local/com/yourorg/yourapp/1.5.67/webapp.war
(depending on how you do your packaging, the WAR file name may include the version number as well).
So your deployment job can construct the Artifactory URL and download the file. Depending on how you have security set up in Artifactory, you may need to authenticate the request.

Resources