If i define a plugin in the <build> tag and want to use this in my site command how do i do that? Do i have to define the plugin within <reporting> tag again?
And how about the configuration which i probably have done within the build tag and want to take place at the reporting tag as well? (i dont want to specifie for example a location of a configuration file twice just to use a plugin in 2 lifecycles)
As example: I define my checkstyle plugin in the build tag and configrue a custom location for the rules to be used. I do that because the rules are packed in a jar so i can define it as dependency. This would not be possible if i do it in the reporting tag. But i need to use this plugin in the reporting tag aswell so surfire can generate a report for checkstyle. So i have to define the plugin within the reporting tag aswell.
Maybe i'm doing something complete wrong here but i don't see how i can do it other then that. What i dont like is that i have 1 plugin twice in my pom (in the build tag and reporting tag).
I hope somebody can verify my solution is ok, or give me an advise how to do it better.
thx
kuku
A maven plugin is typically bound to execution in a given lifecycle phase when you define it. The plugin itself specifies which lifecycle phase this is, but you can change this if you have special needs.
If you have a multi-module build you can define a set of plugins with all parameters required in a common parent-pom. This will normally be executed for every sub-module in the build. If you do not want this to happen you can define it (in the parent pom) like this:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
... More plugin cofniguration stuff ...
</plugin>
If you in one or more nested moudules want to enable this plugin you can just say:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skip>false</skip>
</configuration>
... Maybe Configuration ....
</plugin>
In that specific module. You can choose if you want to reconfigure the default parameters which are inherited from the parent definition or not.
I think this is what you're looking for ?
In addition to KRosenvold's answer, you can also minimize configuration by declaring a plugin in the <pluginManagment> section, perhaps at your topmost pom in the inheritance chain, and then you can omit specifying the version of the plugin in all the other places you are declaring it's use.
Parent Pom:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.2-beta-1</version>
</plugin>
</plugins>
<pluginManagement>
Child Pom:
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
</plugin>
</plugins>
Related
I want to put the hibernate3-maven-plugin in my parent pom and have execution skipped in child modules if a given file does not exist in that module.
Is there any way to do this?
Up to now, I have had to do this:
<plugin>
...
<configuration>
<skip>true</skip>
<propertyfile>target/test-classes/jdbc.properties</propertyfile>
</configuration>
</plugin>
In the parent POM, and:
<plugin>
...
<configuration>
<skip>${maven.test.skip}</skip>
</configuration>
</plugin>
In all child POMs where I want it to execute. I.E Those actually having a jdbc.properties file.
You may be able to do this with profiles, but I suppose you'd probably not want to run it in the parent project, which may be problematic.
Here are some links on profiles:
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
http://www.sonatype.com/books/mvnref-book/reference/profiles.html
http://mindthegab.com/2008/12/02/howto-give-your-multimodule-maven-build-subprojectenvironment-specific-behavior/
This question, had a similar issue and was not able to solve it with profiles:
activate-different-maven-profiles-depending-on-current-module
I'm not 100% on the logistics but you could possibly use the maven exec plugin in combination with a shell script. The shell script would check for the presence of the file and then invoke the mvn plugin using the maven pom directory - which can be obtained and passed to the shell script via the Maven environment variables.
I can easily see if there are conflicts between (transitive) dependency versions using:
mvn dependency:tree -Dverbose=true
... this will show the full resolution tree, including which elements were omitted (for duplicate or conflict or whatever). What I would like to do is to add the full tree to the 'mvn site' report.
Currently, the site report includes the dependency tree but only as resolved, i.e., without any conflicts. I see in the project-info-reports plugin that there is not currently any way to do what I want using the standard report.
I tried adding a section to the pom to include the maven-dependency-plugin 'tree' goal with the outputFile specified, but it wasn't included when I ran 'mvn site'. It was something like this:
<reporting>
....
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<reportSets>
<reportSet>
<id>deptree</id>
<reports>
<report>tree</report>
</reports>
<configuration>
<verbose>true</verbose>
<outputFile>${project.reporting.outputDirectory}/deptree.txt</outputFile>
</configuration>
Of course, the 'tree' goal is explicitly identified as not a report, but I was hoping to at least be able to produce a file that I could link to from the generated site. No dice.
Is there any way to force an arbitrary plugin's goal to execute during site generation? Am I totally out of luck here? Obviously I could write my own reporting plugin to do this, and/or submit a patch for the project-info-reports plugin, but I want to make sure I've exhausted all the built-in maven options.
(I'm using maven 2.1.0, but I didn't see anything about a change to this functionality in the release notes for later versions.)
Is there any way to force an arbitrary plugin's goal to execute during site generation? Am I totally out of luck here?
Just to answer your question, you can bind a mojo to the pre-site phase of the Site Lifecycle:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>tree</id>
<phase>pre-site</phase>
<goals>
<goal>tree</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
...
</reporting>
If you then run mvn site, dependency:tree will run.
I am new to maven and chekstyle, so need to ask some question... I want to use checkstyle in my maven based project, so in my pom.xml I have add the dependency
<dependency>
<groupId>checkstyle</groupId>
<artifactId>checkstyle</artifactId>
<version>2.4</version>
</dependency>
and also I have added the entry in plugin tag:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.4</version>
<configuration>
<enableRulesSummary>true</enableRulesSummary>
<configLocation>checkstyle.xml</configLocation>
</configuration>
</plugin>
But when I run my maven build with command mvn clean install, checkstyle doesn't do anything. And as I dont have any checkstyle.xml in my system yet, shouldn't it complains me about the error?
What else configuration am I missing?
I want to use checkstyle in my maven based project, so in my pom.xml I've add the dependency (...)
You don't need to add this dependency, you just need to declare the plugin (a plugin declares its own dependencies).
(...) But when I run my maven build with command mvn clean install, checkstyle doesn't do anything.
Yes because you only declared the plugin, you did not bind the check goal to a lifecycle phase, so a normal build doesn't trigger the checkstyle plugin. If you want checkstyle:check to be triggered as part of your build, you need to declare the check goal inside an execution (it binds itself by default to the verify phase). Something like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<!-- Lock down plugin version for build reproducibility -->
<version>2.5</version>
<configuration>
<consoleOutput>true</consoleOutput>
<configLocation>checkstyle.xml</configLocation>
...
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Now, calling any phase including verify will invoke checkstyle.
And as I don't have any checkstyle.xml in my system yet, shouldn't it complains me about the error?
It will... when called (either explicitly by mvn checkstyle:check or as part of the build if you modify your setup as suggested).
Using Maven war plugin, I generate WAR which includes following directory:
META-INF
-- maven
-- com.abc.def
-- myServlet
-- pom.xml
-- pom.properties
In release, I want to exclude this maven directory. How can I do that?
I tried latest maven-war-plugin (2.1-beta-1), it has configuration "packagingExcludes", but it doesn't work as I wish.
Any suggestions?
I'm not sure but I think that the Maven Archiver (which is mainly used by plugins to handle packaging) can be configured to achieve this.
About the <addMavenDescriptor> element, the Maven Archiver Reference says:
Whether the generated archive will contain these two Maven files:
The pom file, located in the archive in META-INF/maven/${groupId}/${artifactId}/pom.xml
A pom.properties file, located in the archive in META-INF/maven/${groupId}/${artifactId}/pom.properties
The default value is true.
So a pom configured like this should do the trick:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<configuration>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
</configuration>
</plugin>
...
</plugins>
</build>
...
</project>
Using the standard Maven packaging you can't omit the file to my knowledge. It is possible however to use the maven-assembly-plugin to construct the war, in this case you have much finer grained control over the contents of the artifact, and can omit the pom.xml.
However I have personally found it useful to keep the pom.xml for diagnostic purposes. It can be handy to know what was used to build and assemble the war when trying to figure out what is wrong with your app.
Update: in a bizarre bit of synchronicity to Pascal's answer, I've just been reading up on the Archiver reference and it appears that this can be done by setting the addMavenDescriptor property to false. Personally I would still avoid doing this for reasons given above. But you may want to change your acceptance to Pascal's answer.
Putting a META-INF folder in a resources directory or in the root of your source directory will destroy the META-INF content created by Maven. For WAR files, putting a META-INF in your web content directory will do the same.
Adding other content to that custom META-INF will override what maven would create.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<warSourceExcludes>pom.xml</warSourceExcludes>
</configuration>
</plugin>
or
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1</version>
<configuration>
<warSourceExcludes>here/there/everywhere/a/pom.xml</warSourceExcludes>
</configuration>
</plugin>
I just found something that sounds weird with Maven plugin management.
While working on the site generation I wanted to use a specific version of the maven site plugin in order to have a specific functionnalty working.
Let's say I want to use version 2.0.1 of this plugin.
If I use the reporting section of my POM in order to generate my project's site with the command:
mvn site
this works well. I mean the plugin version used is 2.0.1 as I wanted. Here is an extract from my POM configuring the site plugin:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
</plugins>
</reporting>
Now if I want my site to be generated during a specific phase of the build life cycle, let's say prepare-package (and goal stage), I add the following section in the section:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>stage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
And here I am stuck with the maven site plugin version coming from the Super POM, ie. 2.0-beta-7.
Even if I try to add the configuration specifying I really want to use version 2.0.1 it still uses 2.0-beta-7.
I also tried to add the version in the section because the config that is used in the reporting section is supposed to be applied to the build section also. But this does not work neither.
Maybe I missed something, and correct me if I am wrong but this looks like a bug.
Is there a need on the Maven side to fix plugin's version to be used during the build process?
Thanks!
If you define a pluginManagement section in the pom, you can declare the versions used for any plugins, this will override the versions inherited from the super POM
For example:
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<version>2.0.1</version>
</plugin>
</plugins>
</pluginManagement>
You can refer to the documentation for some background on configuring pluginManagement.
I think you need to use the "pluginManagement" section to set the global version number of the plugin.