I use the git-describe maven plugin to replace the POMs <version>${describe}</version> placeholder. mvn deploy needs a custom parameter passed in order for it to properly use the actual git describe value.
I'm now using Jenkins to build the project every time we push to the repo however it too doesn't properly use the actual git-describe value.
The jenkins build artifacts always end named project-${describe}
Are there any suggestions on ways I can customize the file names or force it to use the git-describe result? Otherwise I may be back to manual versioning...
The version property does not allow variable substitution. The first link I found googling this was this SO question.
You'll have to use one of the versioning maven plugins. The maven release plugin is the most popular, but you might find that the versions maven plugin better meets your requirements.
Related
I am learning about Jenkins and I have to explore some existing build jobs that others wrote (in the company that I'm working).
So I am trying to understand a job which uses mvn command.
So under the build part (inside the job), I see these details:
Maven version: 3.0.5
Root POM: pom:xml
Goals and options: clean install -U -Pnotest,docs
I'm trying to understand what this mvn command means?
I tried to google it: "clean install -U"
But I didn't find what the parameter U means.
And I don't know what is "-Pnotest,docs".
can you guide me regarding how I can find what's it? (maybe "-Pnotest,docs" is from a xml file or it's from the artifactory etc..)
Thanks a lot!!!!
-U Forces a check for miss releases and updated snapshots on remote repositories
If Maven is regularly used in your company, and you will have to work with it on a day-to-day basis, I would advise you to find a mentor (any colleague that knows the tool well and is ready to share its knowledge with you) and work with them. Maven, when you first look at it, can be quite of a mouthful and you'll learn it more efficiently with their help.
For the problem at hand, Elarbi Mohamed Aymen's answer already tells you what the -U flag corresponds to. As for -P, it is used to activate profiles (in your case notest and docs). These profiles are usually defined in the pom.xml of the project being build.
See Running Apache Maven for the basic commands, and as advised on that page run mvn -h to have the complete list of flags the command can use.
Maven is one of the mechanism how to handle the build process and check project dependencies, especially for Java.
One of the option can be to have physically included dependencies (artifacts / libs) in the project, but its not so useful- in case of new version, you have to replace the file, sometimes you are using same lib in more apps, ten you have to handle it manually in all projects.
Except this, there is the maven- it has a global repository with shared artifacts / libs , which are common used- ref. https://repo1.maven.org/maven2/.
Except this, you can make your own libs/ artifacts in this case, its a modules / applications which are reusable, then you are storing it in private repository- this is the artifactory.
When you want to build your project, in case of maven project you have pom.xml , which is like manual for maven what to do / how to build.
clean and install are common goals, clean will wipe your local maven repository, install will download them again, with parameter -U it force to download them.
You can define your own goals in pom file, eg. to "tree build"- build some dependent modules, then build parent project.
Eg. with -D you pass parameters to the maven eg.
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app
- that will generate new project, based on given archetype- "template", with the given groupID and artifactID- groupID can be eg. company name, artifactID is then the name of specific app / component.
-P,--activate-profiles <arg> Comma-delimited list of profiles
to activate
-D,--define <arg> Define a system property
We're building feature branches into a version 'feature_'. Each feature build will produce the same version. Since these are no releases, I want to deploy the artefacts into the Snapshots repo, but Nexus does not allow versions without 'SNAPSHOT' into the Snapshot repo.
How to configure Nexus to allow any version in a repo?
Solved it by appending '-SNAPSHOT' to the branch version.
It's quite tricky to get Maven in Jenkins to use the right version. The way I solved it now is like this. In the build job configure Git to build the branches origin/feature/*. Then:
In the 'build' section, first thing to do is execute a shell command to construct a file 'env.properties' containing the feature branch version to be used by the Maven build command.
echo BRANCH_VERSION="feature_${GIT_BRANCH##*/}-SNAPSHOT" > env.properties
This uses the GIT_BRANCH environment property of Jenkins. The '##*/' is a Bash Shell Parameter Expansion which strips everything from the parameter value except the part after the last '/' character.
Then use the Environment Injector Plugin to 'inject environment variables' to the build job using the 'env.properties' created in the previous step.
Put 'env.properties' in the 'Properties File Path' field.
Use Maven to build a versioned pom with the correct version using 'Invoke top-level Maven targets':
help:effective-pom -Dbuild.number=${BRANCH_VERSION} -Doutput=versioned-pom.xml. This step is necessary because otherwise the pom in the jar artefact does not contain the correct version causing other problems.
Use another 'Invoke top-level Maven targets' step to do the actual build and deploy using the pom version created in the previous step: -f versioned-pom.xml clean source:jar deploy
That's all folks. If anyone knows a simpler solution, let me know.
This is actually a Maven restriction. You can still use version like feature_x-1.2.3-SNAPSHOT though.
What are you actually trying to achieve though?
I am unable to edit pom.xml. Is there a way to define final name of the maven artifact built by Hudson, something like this
<finalName>${project.artifactId}-${project.version}-${timestamp}</finalName>
Since mvn -DfinalName="xxx" on command line does not seem to work.
I am looking for Hudon/Jenkins feature to achieve this as well, or modifying settings.xml in maven repo. Basically any method except editing pom.xml
First, you could have a second build step (execute shell or windows batch) to simply rename the artifacts. Obviously, this will forego the automatic maven module artifacting, but are you using that? If not, just archive the file with post-build actions directly on Jenkins or repository of choice.
Second, the moment you check out the files from SVN, you do have access to modify them in your local workspace. Just don't commit them back to repository.
You could run a regex replace to look for <fileName>.*</filename> and replace with whatever you want.
I have a maven multi module project with several modules. I want to deploy them (mvn deploy) only if they all pass a full mvn install (which includes the tests).
Currently, I run a mvn install on the project. If all modules pass, I run mvn deploy to do the deployment. The problem I see is the waste of time calling mvn twice (even if I skip tests on the second run).
Does anyone have an idea on this?
EDIT: I have learned that using Artifactory as a repository manager and the maven-artifactory-plugin with your maven setup will add the atomic deploy behaviour to the mvn deploy command. See the Build Integration section in the Artifactory documentation.
[DISCLOSURE - I'm associated with JFrog. Artifactory creator.]
Take a look at the deployAtEnd parameter of Maven Deployment plugin: http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html
This is a bit tricky. Maven is not atomic when it executes the build life-cycle. So a broken set of artifacts may end up in a repository.
One solution I know is Nexus Pro: http://www.sonatype.com/Products/Nexus-Professional/Features - it allows you to promote builds or define certain repos as staging. So only verified versions get promoted to be used. Maybe artifactory has something similar - I just don't know.
If that solution is too expensive you probably need to create a cleanup build or profile to remove artifacts that where already uploaded. My first guess would be to write a Maven plugin to use the the proxy remote API or maybe the maven features are already sufficient. But since deploy means update the meta-data xml files too I dont think there is a delete - not sure on this either.
We currently use Maven (v2.2.1) to manage our Java projects, including using release:prepare and release:perform to version our releases.
While this is all pretty simple, I find myself needing to produce the build artifacts from a previous release - is it possible to have maven checkout a given (svn) tag, and build the artifacts from that version?
ie. I have the following tags for a project in SVN:
project-1.0.0
project-1.0.1
project-1.1.0
I would like to build 'project-1.0.1' (or in fact any tag from that project).
Edit:
In order to clarify what I'm trying to do, consider the release:prepare and release:perform goals.
During :prepare and :perform Maven asks what SCM tag should be used for this release, and afterwards creates the tag, checks out the source for this tag into a separate directory in order to produce a sort of cleanroom build of your project.
What I would like to do is actually perform this last part, whereby I supply the SCM tag (on the command line, rather than hard coding it in the pom, as that would not be particularly flexible), and Maven happily goes off to checkout the code and perform a cleanroom build, resulting in the final build artifact, in exactly the same way as release:perform.
You may want to look at bootstrapping a project using maven scm plugin.
By defining a pom, which contains your scm configuration with the specified tag, as well as the desired maven goal, you can checkout a tag of your choice and build the same.
The link contains an example configuration.