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.
Related
I would like to know if it is possible to set up a rule that marks a generated sources folder as generated sources root in Intellij Idea automatically.
Usually, Intellij detects the target/generated-sources directory as generated sources. My problem is that I also need it to automatically recognize the directory target/generated as generated sources, which Intellij never did in my case.
This is because of a maven plugin that I use for generating code from XSD schema:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-xjc-plugin</artifactId>
<version>${cxf.version}</version>
<configuration>
<extensions>
<extension>org.apache.cxf.xjcplugins:cxf-xjc-dv:${cxf.version}</extension>
</extensions>
</configuration>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>xsdtojava</goal>
</goals>
<configuration>
<xsdOptions>
<xsdOption>
<xsd>src/main/resources/schema.xsd</xsd>
<packagename>org.example.project.common.request</packagename>
</xsdOption>
</xsdOptions>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
For some reason, this plugin generates code into the target/generated directory, and not into the target/generates-sources, of which I read that it is the convention and the default from many points of view.
I've tried searching on the web with similar keywords like in the title, but this was the closest solution to what I wanted to achieve. And even this solution doesn't solve my problem because Intellij doesn't allow setting some path patterns; it only offers a few options that don't include target/generated directory.
Another solution suggests changing the target output, which I can't do in every single project I work on; that is not a solution either.
This is important to me because I work with many projects, and sometimes when my code builds with maven but doesn't compile with Intellij I forget to check whether I marked all the generated folders as sources, or I don't even know there are generated sources in the project.
Does someone know a way I can achieve that Intellij automatically detects source files in target/generated directory?
I have a project that consist of 3 different libraries. When I run install script it takes all libraries from repo and run mvn clean install on them. But this version of library already installed in repo. Is there a way to skip install phase if version in pom.xml equal version in my local repo.
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
You can bypass like this
-Dmaven.install.skip=true
<profiles>
<profile>
<id>skipInstall</id>
<activation>
<property>
<name>maven.install.skip</name>
<value>true</value>
</property>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Last week Olivier Lamy patched this jira.
MINSTALL-73
Most maven plugins can be skipped by specifying something like:
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
you can also set up build profiles to set properties and use that to determine the value. for example, running the command: mvn -Pexample would select the "example" profile. The POM would then contain:
...
<properties>
<skip.install>false</skip.install>
...
</properties>
...
<profile>
<id>example</id>
<properties>
<skip.install>false</skip.install>
</properties>
</profile>
...
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>${skip.install}</skip>
</configuration>
</plugin>
...
Using these POM additions, the default behavior for the install plugin will be to perform its default goal, but if the example profile is selected, then the install plugin will skip its goal.
Using what I learned from the other answers, this was the cleanest result for me.
In my super pom I added a pluginManagement/plugin to disable default-install and default-test phases when the property deployOnly is set.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
</executions>
</plugin>
So on the command line, I can disable install and test phases by adding -DdeployOnly.
mvn clean install #build and test everything
mvn deploy -DdeployOnly #just deploy it
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
Are you sure you understood correctly what you boss meant? I interpret the above as "don't install third party libraries in your local repository, use only libraries available in public repositories". This is different from "don't use your local repository" which is basically impossible, that's just not how maven works. I'd try to clarify this point.
Apart from that, I don't get the question which is very confusing (what repo are you talking about? What is the install script doing? Why do you call clean install on libraries? etc).
Extending the other answers, from the future.
Maven plugins have a surprisingly high freedom, how do they run. If they want, they can ignore/override the typical pom.xml settings. Furthermore, also the <configuration><skip>true</skip></configuration> is only a convention, nothing obligates a plugin to follow it, except that most of them is developed so.
My experiments with the recent problem show, that both #Cemo's and #MiloshBoroyevich solution should be utilized, also the plugin requires both to really let us in peace. More concretely, the only working configuration by me was this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
One of your options is to put the deployment to another module. I.e. have one pom.xml build the artifact and install it to the local repo, and another pom.xml to deploy it. This separation is quite common in larger projects, where the testsuite is sometimes a separate module or even a project, the packaging happens in several stages, etc.
- pom.xml - myProject-root - type=pom
- pom.xml - myProject-artifact - type=jar
- pom.xml - myProject-deploy - type=pom, does the deployment, skips it's own `install` goal
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).
I have a multi-module project and I want to deploy on the project's site an HTML version of my source code using the JXR maven plugin.
The problem is that the JXR plugin runs well, the XREF folder is properly generated for each of my module, but when I use the mvn site:stage command in order to retrieve all the project's site content and to have all link properly generated it does not retrieve the XREF folders.
Here is an extract of my POM file where the JXR plugin is configured:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jxr-maven-plugin</artifactId>
<configuration>
<aggregate>true</aggregate>
</configuration>
</plugin>
Here is the command I use to create and stage my site:
mvn site site:stage
Do you guys have any idea?
Thanks in advance.
r.
Not sure this is relevant, but your command is running the site twice, mvn site will generate the site, and site:stage will also run the site, perhaps this is causing problems but I honestly can't see why.
Looking at the JXR documentation, it only mentions the site:site goal, I can't see why it wouldn't be run properly for the site:stage goal as it extends it. If you run the site goal, then copy the output to another directory, run the site:stage goal and compare the output it might give some insight into the problem.
Update: I tried this myself and the xref was included and aggregated nicely in c:\test\stage with the cross references correctly managed. I've included the configuration I used.
In my parent pom I defined the site configuration like this:
<build>
<plugins>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>stage</goal>
</goals>
</execution>
</executions>
<configuration>
<stagingDirectory>c:\test\stage</stagingDirectory>
</configuration>
</plugin>
</plugins>
</build>
The distributionManagement section was configured with the site information (not really needed as I set the stagingDirectory above, but the goal won't run without it).
<distributionManagement>
<site>
<id>mojo.website</id>
<name>Mojo Website</name>
<url>scp://test/</url>
</site>
</distributionManagement>
My JXR configuration in the parent pom was as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<reportSets>
<reportSet>
<id>src-xref</id>
<reports>
<report>jxr</report>
</reports>
</reportSet>
<reportSet>
<id>test-xref</id>
<reports>
<report>test-jxr</report>
</reports>
</reportSet>
</reportSets>
<configuration>
<aggregate>true</aggregate>
</configuration>
</plugin>
The commandline run was mvn clean site:stage
Edit: Per the comments, there is a codehaus jxr plugin with slightly different semantics. Be sure to use the org.apache.maven.plugins version rather than the org.codehaus.mojo version.