I believe that the answer will be really easy, but I haven't figure out how to do it.
The problem is:
I have a third-party project, which is being cloned from github, so I'm not going to change anything there, but I need this project for my work with MUnit.
The project is mule-interceptor-module and it has a version 3.4-M4-SNAPSHOT.
I created a build in Jenkins and I want to get mule-interceptor-module-3.4-M4-SNAPSHOT.jar after it, but Jenkins REMOVES -SNAPSHOT from the jar name and updates pom.xml with new version: 3.4-M4 instead of 3.4-M4-SNAPSHOT. The project, which uses this one (munit) in its dependencies has 3.4-M4-SNAPSHOT. So I need the SNAPSHOT in version.
What I tried to do:
I tried to build the same project on the server, which my Jenkins is installed on, using just mvn clean install and I got mule-interceptor-module-3.4-M4-SNAPSHOT.jar.
The question is:
How to tune Jenkins so that I could finally have SNAPSHOT build?
My job setup:
JDK: jdk 1.6.0_45
Source Code Management:
Git
Repository URL: https://github.com/mulesoft/mule-interceptor-module.git
Branch Specifier (blank for default):3.4.x
Repository browser: githubweb
URL: https://github.com/mulesoft/mule-interceptor-module/
Pre Steps:
Execute shell: git checkout 3.4.x
Build:
Root POM: pom.xml
Goals and options: clean install
Post steps:
Run regardless of build result
Build Settings:
- Publish Checkstyle analysis results
- Publish FindBugs analysis results
Jenkins Console output
Jenkins Console output wirh -X
The solution:
in Jenkins /Configuration/Build/Advanced check in Use private Maven repository
Choose Strategy: Local to the workspace
remove everything from /workspace folder by rm -R *
#Grove: thanks you a lot for the support!
I can see in the logs: Your branch is ahead of 'origin/3.4.x' by 1 commit. and Building Mule Interceptor Module 3.4-M4. Could it be that your revision has 3.4-M4 as a version in the pom?
The solution:
in Jenkins /Configuration/Build/Advanced check in Use private Maven repository
Choose Strategy: Local to the workspace
remove everything from /workspace folder by rm -R *
Why are using SNAPSHOT dependency from a 3rd party ? The standard is to use a RELEASE version, right ?
Answer Anyways the fact that using the private maven repository worked for you proves just one thing, that the negative cache in your server's maven repo was causing the problem. See this Q and A from me more than a year back, when exactly the same solution worked for me, albiet for a different problem and I marked it as the answer. Only to find a few months later that I did not go to the root cause of the problem and just found a workaorund.
To test this theory, set <updatepolicy> true <updatepolicy> and use maven -U clean install. It will have the same effect as your solution of using a private repo.
Related
I have created pipelines which will clean, compile, test, & deploy the code every time we update it. But in case of a technical issue/or error I want to add a step which allows me to revert/rollback the "build" or deployment.
Is there a maven command that can be used to revert/rollback builds/deployments?
No.
If you just run clean package, then another clean will erase the results of package, but if you have run install or deploy the artifact is send to the local repository or remote repository. This cannot be "rolled back" by Maven.
The Maven Release Plugin has a rollback goal that rolls back the changes that it made to version control:
version changes in POMs are reverted
created tag is deleted
created branch is deleted
However, this rollback does not delete files that were uploaded to the remote repository! If the remote repository does not allow artifacts with final versions to get deleted or modified, then you would end up with a problem, because your next attempt would fail to re-upload.
The Maven Release Plugin internally uses the Maven Deploy Plugin to upload files, and the latter has an experimental deployAtEnd feature. Unfortunately, I did not manage to get it to work for my build (using the suggestion from this SO comment) - I still had a build in which the Maven Release Plugin uploaded files before exiting with a failure.
I got a maven project (myApp) depending on another maven project in snapshot version.
like:
<dependency>
<groupId>org.group.dep</groupId>
<artifactId>arty</artifactId>
<version>12.1.4-SNAPSHOT</version>
</dependency>
But I got a problem with this after the "arty" got an update without changing the version (I know that would be the cleanest solution).
I build the myApp local and got still the old version of the "arty" dependency.
I verified tow option working for me (and a college):
1) Manual cleaning of the local repository: navigating to my .m2/repo/org/group/dep/arty and deleted all folders inside. After rebuilding the myApp local it was working fine - arty was downloaded form the artifactory.company.com again with the updated content.
2) Local building of the arty package so it got updated in the local repository. After rebuilding the myApp local it was working fine.
But I got similar problem on the Jenkins:
I got a Jenkins job just building org.group.myApp without building before org.group.dep.arty. It failed for the missing changes form "arty".
What can I do now to solve my problem there?
I can not rely on first building org.group.dep.arty as I can not be sure for Jenkins to run both jobs on the same host using same local repository (I don't want to change that).
Somehow the myApp-Jobs was failing after I manually cleared on that Jenkins node the org.group.dep.arty in the repository and running than the myApp-job (was somehow not downloading the package).
I finally found the mvn -u but as I tried this I was as well disappointed.
I tried different maven versions on that jenkins and got the same result.
Is there no way to force the update of the snapshot versions?
Is this "another project" is a part of the same multi-module project?
If so you can build your project with --also-make options so that maven will effectively rebuild your module and all of its dependencies
If its an entirely different project, use mvn -U to forcefully download all the snapshot dependencies of your project.
If there is a particular issue with one concrete dependency consider using mvn dependency:get. This get goal of maven-dependency-plugin downloads one specific artifact from the remote repository
Here is a link to the plugin documentation
The simplest solution to redownload -SNAPSHOT is by using the command line option: -U or as long option --update-snapshots
Furthermore your project sounds like the need for a multi module build which prevents such issues. Or you might need to define those Jobs depending on each other (There is an option to build if a SNAPSHOT has been updated in Jenkins).
I have a project being built with maven using TFS for source control and Octopus for deployment.
At the moment, I can perform a TFS CI build, create an octopus deploy package as a zip file from the output, and use octopus to deploy to my deployment target, extract the package and install the app.
What I would like to do is increment the version of the application projects when a new build is performed (perhaps nightly).
Is the correct way to do this, to get my build server to set the new version on the project, using mvn versions:set -DnewVersion=x.y.z then to run mvn deploy to push the updated packages to the networked repository. Then to finally create my maven package from this?
I'm a bit unsure the best way to allow my build server to up issue the versions and then use those updated versions of the packages in the build.
It seems like I may have the wrong end of the stick here. Any pointers greatly appreciated.
If you had already at Maven 3.2 or better Maven 3.3+ you could have done that in a more convenient way, but if you are at Maven 3.1. you need to go
via build-helper-maven-plugin and versions-maven-plugin you can do simply via:
mvn build-helper:parse-version versions:set \
-DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}\${parsedVersion.nextIncrementalVersion} \
versions:commit
But as far as I know the versions:commit will probably not work based on support of TFS for Maven SCM....(I never tested it with TFS). But the commit step be done by something different.
I am new to maven and I heard the term "maven clean repo" building ? What is the meaning of this ? How it different from the normal maven building process ? Also I want to know about the maven repository and how it changes when we build the software
I'm not sure if there is an exact term called "maven clean repo building" - but it is probably referring to doing a clean build by clearing out your entire LOCAL maven repository to ensure you have only the correct dependencies for your project.
All dependencies you need get downloaded into the repository which is at ${user.home}/.m2/repository by default. You can see this grows as the build runs and dependencies get downloaded into this folder.
The link
http://maven.apache.org/plugins/maven-dependency-plugin/examples/purging-local-repository.html explains one way of purging this.
You can change the maven repo being used for the build by providing the following argument to the build command
mvn clean install -Dmaven.repo.local=/tmp/sampleRepo
If relevant artifacts are not available in the pointed maven repo, it will download them from relevant repositories (maven central or repositories which are provided in the pom.xml file).
Hint;) Using a directory in /tmp/ will be more good as /tmp/ get automatically cleared in OS restart.
Today while doing the release of our project, the release:perform command failed in between as our nexus was having intermittent issues. The release command only able to upload one pom file to nexus.
Now, the nexus issue is resolved and I am trying to do the release, it fails as the pom file already exists and its not the snapshot version and we don't have access to nexus so that I can delete that file and start over again.
Is there any way I can pass an argument so that release:perform should continue if the file is already there and ignore this but continue with uploading the rest.
I have looked for options of such type but didn't find anything.
My last resource would be to start the release again, which will bump the version number, but would like to understand if there is any other approach where in I don't need to bump the version.
I am using maven 2.2.1
Here's how I have handled this in the past. The release:perform command does a checkout of the tag from your SCM provider (e.g. SVN). This is done in the target/checkout directory of that project - whatever is there should be an exact copy of the released tag, so it will have the right version number in the pom files etc.
If you move to that directory (target/checkout in the directory where you started the release), you can simply do a mvn deploy there and it should compile and package that version, and then upload it to your Nexus instance.
If you don't have the target/checkout directory, you can check out the Tag created as part of the release:prepare phase from your SCM system to a fresh directory and run mvn deploy there.
Since the tag in your SCM has already been created, the only thing that's left is really compiling, packaging and deploying the release, which is exactly what mvn deploy should do.
If you have provided additional parameters (e.g. for activating profiles) for the build during the call to mvn release:perform, you will have to provide these as well when you run mvn deploy.
Using this approach, your version number will not have to change, it can stay the same, since you're just uploading what has already been tagged as part of mvn release:prepare.
My advice would be for you to request from the admins that the old artifact be removed. You can either re-deploy the code from the tag by checking it out and simply doing
mvn deploy
Or rolling back your release:
mvn release:rollback
And re-doing it as usual.
It is essential to remove the old artifact from the remote repository, if the sizes do not match. Release repositories do not allow the redeployment of artifacts, unless this has been explicitly switched on on the server side.
Furthermore, #nwinkler's answer is also quite good.