I'm trying to set up Jenkins so that when it builds a Maven Job, it should set the build name of that build to include, somehow, the Maven version of that project. If I can't get it to work for all builds, I'd like it to at least work on a maven release.
I've looked into both the Build Name Setter plugin (which is fairly underpowered IMO) and the M2 Release Plugin (which we already use).
I see that the Build Name Setter plugin has access to Environment variables, and I was considering checking whether or not the M2 Release Plugin set any.
I also had a look at this question on SO:
Getting Maven Version in Jenkins
This is some interesting information...Maybe I could modify the Build Name Setter plugin to use some of the code listed there?
Do you guys have any ideas?
I ended up adding code to the M2 Release Plugin (Open Source FTW) to offer the option of appending the version number to the build name on successful builds. I made a Pull request on GitHub a week ago and I haven't heard back (which is fine, it's totally up to them), but I figured I'd mention my solution for anybody that might stumble across this page in the future.
Related
I've been asked to do this, so please don't suggest that I shouldn't need to. :-p
We currently build a multi-module project with Maven. We have no problems doing so. We're using the Maven release plugin, and we get SNAPSHOT builds for development and release builds in Jenkins. The release plugin automagically increments the 3rd place of the version string. Life is good.
But, I've been asked to add a 4th place in our version strings, which is populated with the Jenkins build #.
The canonical way I see suggested to do this works fine with a single module: You define a property like build.number, to have a default value of "0-SNAPSHOT", and you define your POM to have a element value like "1.9.${build.number}". And, you set your Jenkins job to define build.number to be the Jenkins build #, for its invocation of Maven.
That would be great, if we had a single module, but we don't. We have multiple modules, and in Maven I can't either
1. not specify a version in the child module POMs, nor
2. use a property in the version of the child module POMs.
I gather it's a bad idea for Maven POMs to try to produce multiple artifacts in a single module (using. say, profiles), so I don't want to try to smoosh this project down to a single module.
I probably could try instead splitting it into separate projects, except that seems drastic, and besides, this project really is producing very tightly-related artifacts, so I want to be sure to build all the artifacts for any source code change in the project.
Any solutions?
The maven-release-plugin has two parameters named releaseVersion and developmentVersion. There you set the version to build and the next version, respectively.
Using Jenkins, you can fill these variables with Jenkins generated content, using e.g. the build number. If you want to read the parts of the version number from the POM, you can use build-helper:parse-version and use terms like ${parsedVersion.majorVersion}.
I have a number of builds that creates a package that is published to a package manager (for example NPM, Nuget and Maven).
I have subsequent builds that trigger on the completion of this build, they get the artifact from this repository. The problem is they show a warning:
I'm considering adding a Snapshot dependency, however, Teamcity's UI describes snapshot dependencies as builds using the same sources:
There is no source dependency between these projects and in fact, they may have completely different VCS roots.
What is the appropriate way to link these projects? Reading the documentation on Snapshot Dependencies, it sounds like things might not work as expected if I add a dependency without shared sources.
There is no requirement to link these projects, other than by the trigger you already have I don't think.
If the triggered build always gets the latest version from the package manager, then you'll get the behaviour that you want.
Snapshot dependency simply ensures that a build which depends on another build gets the same version of the source code when it builds, and doesn't end up being built using some changes that someone else checked in between the first build starting and the second build starting. This doesn't look like its going to be an issue in your situation (and indeed the builds may use completely different repositories), so I think your finished build trigger is an appropriate solution.
I'm working a contract that has some build oddities... they're using maven, but the pom file is actually edited by the build script to replace the version number with the jenkins build number, and then that same number is used to replace the version of other internal projects which will be used at build time by this project. I am new to maven, but know enough to know this feels wrong.
I can pass in the version number, but putting the same property in the dependency block doesn't seem to work.
I know the tao of maven is serious business, please understand this is a very short term contract and build system isn't in my statement of work - I just want to get to a place where the source controlled files aren't edited by the simple act of running a build.
You can definitely define a Maven property with a version value, and reference it in the dependency declaration. And, with Maven properties, they can be passed into maven using the "-D" command line option.
What I'm not sure of it whether the timing of how Maven runs will allow this to change the dependency version. I think (so, I'm not 100% certain) that the dependency management will be managed before command-line options are processed.
I'd try defining a maven property with the dependency version in it, and reference the maven property in the dependency declaration appropriately. Then, when running mvn, supply the desired version as a property value. That'd be the most-likely approach.
Maven noob here. We have tens of repos with POMs that build rpms and recently moved our CI system to CentOS 6. As a result rpm builds are no longer backwards compatible with RHEL 5. Apparently I need to state within the spec or the maven POM:
<defineStatement>_source_filedigest_algorithm md5</defineStatement>
<defineStatement>_binary_filedigest_algorithm md5</defineStatement>
Can I add this to our parent POM somehow? Otherwise I need to script the addition of these lines to a slew of repositories and that gets ugly and error-prone quickly.
Is that a property? Is that a configuration item for a plugin? If it's a property, you could define a active profile on each machine building it. This would be appropriate if it changes based on the machine running the build. The profile would be defined in the conf/settings.xml of the maven installation, and defined as active if it should be applied to all builds. However, not knowing where that value is meant to be sent, I can only guess right now.
I am trying to write my pom.xml for a multimodal flex application. I have been using this resource as an example:
http://www.sonatype.com/books/mvnref-book/reference/flex-dev-sect-creating-with-archetype.html
I am using M2E v1.01 but I am faced with a number of 'Plugin execution not covered by lifecycle configuration" errors. As far as I can see - there are no m2E connectors available to resolve this and I have tried all the Maven advice I can find - to include:
Clean
Update dependencies
Update project configuration
The problem only occurs if the project is declared as swc or swf package. My next move to ask Eclipse to 'permanently mark goal as ignored' - which seems a little brash.
Any advice would be appreciated.
Thanks in advance.
With STS 2.8.0, we have upgraded m2eclipse to be version 1.0. However, this can cause a bit of trouble with existing projects. I wrote a blog on this a couple of months ago.
http://blog.springsource.org/2011/10/18/upgrading-maven-integration-for-springsource-tool-suite-2-8-0/
Essentially, the new architecture for m2eclipse requires that each maven plugin you use must be mapped to one Eclipse plugin to handle the plugin's execution inside of Eclipse. This obviously causes problems since not every maven plugin author has the knowledge or time to create also create and maintain an Eclipse plugin.
By marking the plugin as ignored, you are saying that the plugin should never be executed inside of Eclipse (implying that whenever you need it to be executed, you will do so from the command line). Once marked as ignored, you can then change it to execute, which means that it should always be executed whenever the associated lifecycle is performed in Eclipse. This may cause performance problems, and so only do it if you know the risks.
If all this is too much for you, then STS provides a downgrade option to revert to an older version of m2eclipse. Go to the Dashboard extensions page. Unfortunately, you will have to manually revert all changes to your .project and .classpath files (we provide an auto-upgrade mechanism, but not a downgrade mechanism...presumably everything is in version control).
Any questions or problems should be sent to the STS forums:
http://forum.springsource.org/forumdisplay.php?32-SpringSource-Tool-Suite
You can check this alpha connector "Flex Maven Integration for Flash Builder" on the eclipse marketplace: http://marketplace.eclipse.org/node/648556.