I want to write a mojo, which responsibility is to validate the POM against a set of rules (in addition to those specified by Maven). As an example, it'll make sure there's an organization element, and that it is populated with the company's details.
This plugin would have the validate phase defined as its default phase, and it would go in the company's parent pom, so that it will be executed upon any build.
The issue is that there are different set of rules that should be applied for snapshot and for release builds.
Now, maven release plugin executes a clean verify after it had done its manipulations (i.e., after release:prepare). And so, my plugin will be executed at this point. Cool.
The thing is, that since it is in the release context, I need to apply the release set of rules. But I cannot tell it is in a release context; I have no idea who/what had triggered it - "regular" build, or as a "sub-process" of release:prepare. There's no indication whatsoever...
One solution could be to have the preparationGoals populated with, for example, clean verify -DisRelease=true, where isRelease is a parameter the plugin queries in order to apply the correct set of rules.
But I do not like this idea; it feels like a hack, and too fragile...
So the question is:
Is there a way to tell what's the context of the execution of the plugin, so that I can tell a snapshot from a release? Is there a way to bind a configuration to a goal, rather than to a phase (as in release it is not a phase, but rather a release:prepare goal)? Is there any other way I can achieve this?
Thanks in advance,
Ohad
------------------ EDIT --------------------
Due to some misunderstandings, I am giving a possible example:
Let's say the organization idea of version is of the format: {number}.{number}.P-{number}, for whatever reason.
So, in "regular" build there will be a check that the version is in the format {number}.{number}.P-{number}-SNAPSHOT, and in case of release, it'll check that it is in the format of {number}.{number}.P-{number}.
The POM starts with the version with -SNAPSHOT, while in CI, and it passes validations. Then, the developer wants to release it. So a release:prepare is executed, chopping of the -SNAPSHOT. Then, as the default of preparationGoals is clean install, the validation rules are executed on the manipulated POM (where the version is without the -SNAPSHOT). It will fail, as it (wrongly) expects the version to be with -SNAPSHOT.
So how can I signal it, that "release" validations should be executed?
Thanks again
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}.
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 have a Maven project that builds a plugin for a third-party system. The third party system requires version numbers to be in the format: YYYYMMDDNN where NN is a build number, and the date should correspond to the release date of the project. We'll call this the "external version". At build time, we use the maven.build.timestamp to set this value, and the maven-release-plugin to filter this value into our sources appropriately.
We also have an internal semantic versioning number scheme, which we use for the ${project.version}.
When we do a release, the maven-release-plugin appropriately transforms the project.version to remove SNAPSHOT, tags it in git, and so on. Is there a way to also "fix" the YYYYMMDDNN version in the at the same time, so that future builds of that release are identical?
You could use the release plugin's preparationGoals to edit the pom.xml locking down the property, and then use completionGoals to unlock it afterwards.
The changes you make in those goals will be committed, and in fact an aim of mine is to provide a goal on the versions maven plugin to lock down ranges and unlock them again for use in the above two steps so that version ranges become almost useable... Just avent had the time, but I did add the completion goals release phase.
I know how to avoid deploying a module during the release process. What is not clear is how to avoid building the module to begin with. For example, my project contains an "examples" module. This takes a very long time to build and is never deployed to Maven Central so I'd like to avoid building it altogether (but only during a deploy). Any ideas?
If you're using the Maven Release Plugin, you will need to take care of both the prepare and the release steps, since projects are usually built in both steps.
For the prepare step, I would try the preparationGoals parameter, which by default uses clean verify, which includes a build of the project. Maybe you can try setting it to clean only to avoid the build.
http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html
For the perform step, take a look at the goals parameter, which by default is set to deploy. You can override this by specifying clean only.
http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html
I haven't tried this exact combination, so I don't know whether this will have any side-effects on the rest of the build.
Best thing in this case is to use a profile and put the example into a separate module which can be activated by a profile. This prevents building during release but can be build during usual development etc. via activating profile.
Ok, this may be a silly question, maybe my English knowledge, or "just" my comprehesnion level, is fooling me, but what is the difference between snapshot dependencies and dependency triggers?
I guess the first means that when you build a project, TC makes sure the dependency is up to date, if it isn't it is rebuilt, and then it builds the original project, plus it won't allow builds in parallel. And the later means that if a new build of the dependency is built, it triggers a build of the project.
Also, if this is the case, I guess any "recursion" problem is already handled, like, eg: you force a build of a project with both features enabled, it checks the dependency and sees it needs to be rebuilt, and when it does so, the trigger isn't fired.
Are my assumptions right?
For the first part of your question, you answered it yourself.
Snapshot dependencies, force the dependent Build Configuration to build (if it's not up to date) before building the current Build Configuration.
Dependency triggers, make the current Build Configuration build after a successful build of the dependent project.
On the second part of your question, I think you are asking if Build Configuration A will run twice when it has both a Snapshot Dependency and a Dependency trigger to Build configuration B and you Run the Build Configuration A.
I tried this myself with Teamcity 5.1.2 and I saw that it only ran once.