I would like to update a property in a given pom to the major+minor version of the new version when I perform a release.
To do this, I need to set goals to run during the release. I can calculate the property ahead of time, but the versions:set-property I've seen elsewhere appears to be gone (according to http://www.mojohaus.org/versions-maven-plugin/ and CLI use), and other goals for this plugin don't seem to be able to handle not using the exact version.
Is there any reasonably simple way to do this, or do I have to shell out to the exec or antrun plugins to do it? Regardless, it seems that there's nothing but text replacing that will fix it. The replacer plugin seems to work, but that requires grabbing the previous version, and would take work to not break other references.
The Maven build helper plugin can set properties using regex. Maybe this is what you need.
Related
We have a maven based Java EE project controlled by the customer. For internal reasons, we cannot execute one of the build steps, but the rest works fine and produces the jar we want.
Since editing the pom file would require taking care when committing to customer's SVN and copying the pom file would require taking care to sync changes comming from there, we are looking for a way to skip this specific step in the build section during the maven call itself, so to say mvn clean install but-leave-out-this-build-plugin-step, is there any?
Edit:
The plugin in question is the rpm-maven-plugin, which prevents the build from running on Windows. We found information how to make it work which won't really fit in our current setup. And since we cannot modify the customer's pom, I was looking for a way to trigger the skipping externally. But maybe there are other ways to just ignore/skip/fake this step?
It depends on what plugin you want to skip. Many plugins have ability to be skipped via system property (-Dblabla).
For deploy plugin it is -Dmaven.deploy.skip=true, for surefire -DskipTests=true.
Read plugin documentation, maybe you can find skip property
The rpm plugin hase a property disabled, unfortunately it is not accessible by a property. So, if setting this property in the customer's pom (or asking for editing it) with a default value of false is an option, this may be the solution.
I've got a question regarding updating dependencies. Im looking for a project that will lookup Maven (and eventually Gradle as well) dependencies based on my current dependencies and get the critical updates. I dont want to auto update everything, since that might mess up compatibility.
Maven already has mvn versions:display-dependency-updates which gives you a list of all outdated dependecies. What would be nice is to have something that takes the results of that command and filters all dependencies for critical/security updates.
Has anyone seen something to do that (or know a hidden mvn command) or should I start scripting?
Cheers!
I have a regular requirement to execute several goals in Maven so I decided to write a plugin for it. It seemed easiest to define a new lifecycle for this, each phase executing the relevant plugin goal. I need to pass configuration to the plugin, specifically a directory and a version number.
I found that if I use a variable in lifecycle.xml, such as ${projname.directory}, the variable appears to be resolved not at plugin compile time but at project compile time. I'm guessing that lifecycle.xml is used within the project and not touched by the plugin. Is there any reference for understanding exactly how this works?
Also, I'd like to be able to use a default directory name if the projname.directory property is not set - storing this in the plugin source somewhere. I have no idea how to go about this - is there an easy way to do it?
Thanks,
-Dave
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.
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.