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
Related
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.
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 understand that the maven-compiler plugin is used to compile the code. Some of my project does not have that plugin in the pom file? When is it required?
I am trying to answer my own question based on what I learned since posted this question. If this answer is correct or incorrect please comment. Thanks.
If this plugin is not defined, the Maven Super POM contains all the default plugins you will be using. It works fine for small and non-serious projects. However, the best practice is to define these plugins in a company-wise POM and so that when you upgrade maven, you would not end up using a different version of plugin.
Have a look at the Goals Overview Section in Apache Maven Compiler Plugin
The Compiler Plugin has two goals. Both are already bound to their proper phases within the Maven Lifecycle and are therefore, automatically executed during their respective phases.
You only have to add it if you want to change the default parameters
I am working on a project and using Maven to build it. The project is a quite big Java web application and it is supposed to work with both Mysql and Oracle databases.
The problem is that there are some specific annotations related to either of the two databases in the source code, plus some other differences, so that I am forced to manually comment/uncomment part of the code before building the application for one of the two databases.
Basically what I would like to achieve is to have my build script, maybe via a Maven profile, to automatically switch the source classes before building depending on the database I want my war to work against.
Putting it simply, the idea is to have MyClass.oracle and MyClass.mysql, and depending on my build profile I should move one of the two in the source dir, rename it MyClass and build. This should be done for some packages, classes, and also configuration files.
Is there any way I can achieve it via "pure" Maven? The only solution I came across till now is to use an antrun plugin and reference an Ant build.xml inside of it.
Thank you,
Mattia
A pure maven solution would be to develop your own maven plugin. Depending on your requirements this can be an overkill, however it is not hard at all, you can see how to achieve this here.
This is a limitation of Maven. One of Maven's purposes is to not have a build script. You should simply use the plugins as available, and setup your project the right way, and magically, everything will build!
There is one solution: Use Ant. Well, not to redo your whole project with Ant, but with the antrun plugin, you can run a few Ant tasks at various phases of your Maven build life cycle.
It's been a long, long time since I've used this, so I am not going to try to write a test pom.xml, but I don't remember it being very difficult to use.
Of course, the correct Maven solution is to divide your project up into "common core" code, and then a separate Oracle and MySql client that uses the "common core". By the way, I hope you're not patching source code. Instead, you're using a properties file to do this for you.
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.