Maven 2 & 3

support <dependencies> in <reporting> plugins

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Plugins and Lifecycle
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

Inconsistency with rest of design.

Issue Links

Activity

Hide
John Allen added a comment -

Note that a work around for this issue is to configure the reporting plugins and their dependencies as part of your build in the <pluginsManagement> section of your POM, as they are reporting plugins they wont bind to a lifecycle phase (well PMD and checkstyle dont) and will thus be dormant in a normal build.

However due to the way maven does things (a nice way of saying a bug depending upon perspective) when you run site:site the plugins referenced by <reporting> will use their <pluginsManagement> configured dependencies and will thus find resources in the custom jars youve specified.

Note, if youre activating the reporting plugins via a <profile> in a child POMs you need to (pre)configure those reporting plugins in the <build><plugins> section of your parent POM rather than the <pluginsManagement> section due to another bug that prevents specified depenedencies from being picked up in child POMs when activated from <profiles>.

Extract from my parent POM:-

<build>

<plugins>

<!-- Maven bug workaround: plugins used in the <reporting> section can not have
<dependencies> specified (JIRA MNG-2173) and as there is no <reportingManagement> section
we can not set them up in a parent POM (JIRA MNG-1931) so we need to configure
these reporting plugins as if they were part of the build even though they are only used
in reporting so they can access their required dependencies. (fortunately they do
not bind themselves to a lifecycle stage so they do not get run in the normal build) -->

<plugin>

<artifactId>maven-pmd-plugin</artifactId>
<dependencies>
<dependency>
<artifactId>pmd</artifactId>
<groupId>com.fujitsu.abs.build-resources</groupId>
<version>1.1-SNAPSHOT</version>
</dependency>
</dependencies>
<configuration>
<rulesets>
<ruleset>pmd-fujitsu.xml</ruleset>
</rulesets>
<format>xml</format>
<linkXref>true</linkXref>
<sourceEncoding>utf-8</sourceEncoding>
<minimumTokens>100</minimumTokens>
</configuration>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<dependencies>
<dependency>
<groupId>com.fujitsu.abs.build-resources</groupId>
<artifactId>checkstyle</artifactId>
<version>1.1-SNAPSHOT</version>
</dependency>
</dependencies>
<configuration>
<outputFileFormat>xml</outputFileFormat>
<xrefLocation>xref</xrefLocation>
<configLocation>checkstyle-fujitsu.xml</configLocation>
</configuration>
</plugin>

</plugins>

Usage in my child POM:-

<reporting>
<plugins>
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<outputFileFormat>xml</outputFileFormat>
<xrefLocation>xref</xrefLocation>
<configLocation>checkstyle-fujitsu.xml</configLocation>
</configuration>
</plugin>
<plugin>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<rulesets>
<ruleset>pmd-fujitsu.xml</ruleset>
</rulesets>
<format>xml</format>
<linkXref>true</linkXref>
<sourceEncoding>utf-8</sourceEncoding>
<minimumTokens>100</minimumTokens>
</configuration>
</plugin>

[SNIP]

<profile>

<!-- these profile adds code quality tests to the build lifecycle,
any failure to meet the defined standards will result in the build
failing -->

<id>enableGovernanceChecks</id>

<activation>
<property>
<name>abs.enableGovernanceChecks</name>
<value>true</value>
</property>
</activation>

<build>

<!-- there's a maven bug that results in a NPE if we dont have specify of these (JIRA: ???) -->
<pluginManagement />

<plugins>

<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
<dependencies>

<!-- This shouldnt be necessary as the checkstyle plugin is configured by a parent
project however due to a maven bug (JIRA: MNG-2174) the plugin's dependencies are not
propogated to child projects so we need to restate the dependency here -->

<dependency>
<artifactId>checkstyle</artifactId>
<groupId>com.fujitsu.abs.build-resources</groupId>

<!-- Due to a maven bug (JIRA: MNG-2172) the version info for plugin dependencies
can not be specified in the <dependencyManagement> section so we must
explicitly specify the <version> to use here -->

<version>1.1-SNAPSHOT</version>

</dependency>
</dependencies>
<executions>
<execution>
<id>standards-conformance</id>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

<plugin>
<artifactId>maven-pmd-plugin</artifactId>

<dependencies>

<dependency>
<artifactId>pmd</artifactId>
<groupId>com.fujitsu.abs.build-resources</groupId>
<version>1.1-SNAPSHOT</version>
</dependency>

</dependencies>

<executions>
<execution>
<id>standards-conformance</id>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

<plugin>
<artifactId>maven-clover-plugin</artifactId>
<executions>
<execution>
<id>standards-conformance</id>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>

Show
John Allen added a comment - Note that a work around for this issue is to configure the reporting plugins and their dependencies as part of your build in the <pluginsManagement> section of your POM, as they are reporting plugins they wont bind to a lifecycle phase (well PMD and checkstyle dont) and will thus be dormant in a normal build. However due to the way maven does things (a nice way of saying a bug depending upon perspective) when you run site:site the plugins referenced by <reporting> will use their <pluginsManagement> configured dependencies and will thus find resources in the custom jars youve specified. Note, if youre activating the reporting plugins via a <profile> in a child POMs you need to (pre)configure those reporting plugins in the <build><plugins> section of your parent POM rather than the <pluginsManagement> section due to another bug that prevents specified depenedencies from being picked up in child POMs when activated from <profiles>. Extract from my parent POM:- <build> <plugins> <!-- Maven bug workaround: plugins used in the <reporting> section can not have <dependencies> specified (JIRA MNG-2173) and as there is no <reportingManagement> section we can not set them up in a parent POM (JIRA MNG-1931) so we need to configure these reporting plugins as if they were part of the build even though they are only used in reporting so they can access their required dependencies. (fortunately they do not bind themselves to a lifecycle stage so they do not get run in the normal build) --> <plugin> <artifactId>maven-pmd-plugin</artifactId> <dependencies> <dependency> <artifactId>pmd</artifactId> <groupId>com.fujitsu.abs.build-resources</groupId> <version>1.1-SNAPSHOT</version> </dependency> </dependencies> <configuration> <rulesets> <ruleset>pmd-fujitsu.xml</ruleset> </rulesets> <format>xml</format> <linkXref>true</linkXref> <sourceEncoding>utf-8</sourceEncoding> <minimumTokens>100</minimumTokens> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-checkstyle-plugin</artifactId> <dependencies> <dependency> <groupId>com.fujitsu.abs.build-resources</groupId> <artifactId>checkstyle</artifactId> <version>1.1-SNAPSHOT</version> </dependency> </dependencies> <configuration> <outputFileFormat>xml</outputFileFormat> <xrefLocation>xref</xrefLocation> <configLocation>checkstyle-fujitsu.xml</configLocation> </configuration> </plugin> </plugins> Usage in my child POM:- <reporting> <plugins> <plugin> <artifactId>maven-checkstyle-plugin</artifactId> <configuration> <outputFileFormat>xml</outputFileFormat> <xrefLocation>xref</xrefLocation> <configLocation>checkstyle-fujitsu.xml</configLocation> </configuration> </plugin> <plugin> <artifactId>maven-pmd-plugin</artifactId> <configuration> <rulesets> <ruleset>pmd-fujitsu.xml</ruleset> </rulesets> <format>xml</format> <linkXref>true</linkXref> <sourceEncoding>utf-8</sourceEncoding> <minimumTokens>100</minimumTokens> </configuration> </plugin> [SNIP] <profile> <!-- these profile adds code quality tests to the build lifecycle, any failure to meet the defined standards will result in the build failing --> <id>enableGovernanceChecks</id> <activation> <property> <name>abs.enableGovernanceChecks</name> <value>true</value> </property> </activation> <build> <!-- there's a maven bug that results in a NPE if we dont have specify of these (JIRA: ???) --> <pluginManagement /> <plugins> <plugin> <artifactId>maven-checkstyle-plugin</artifactId> <dependencies> <!-- This shouldnt be necessary as the checkstyle plugin is configured by a parent project however due to a maven bug (JIRA: MNG-2174) the plugin's dependencies are not propogated to child projects so we need to restate the dependency here --> <dependency> <artifactId>checkstyle</artifactId> <groupId>com.fujitsu.abs.build-resources</groupId> <!-- Due to a maven bug (JIRA: MNG-2172) the version info for plugin dependencies can not be specified in the <dependencyManagement> section so we must explicitly specify the <version> to use here --> <version>1.1-SNAPSHOT</version> </dependency> </dependencies> <executions> <execution> <id>standards-conformance</id> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-pmd-plugin</artifactId> <dependencies> <dependency> <artifactId>pmd</artifactId> <groupId>com.fujitsu.abs.build-resources</groupId> <version>1.1-SNAPSHOT</version> </dependency> </dependencies> <executions> <execution> <id>standards-conformance</id> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-clover-plugin</artifactId> <executions> <execution> <id>standards-conformance</id> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile>
Hide
John Allen added a comment -

This has become a complete show stopper for us.

Is there no progress/thoughts/concern regarding this?

Many plugins require licenses and other auxiliary files and, this being maven and about a reproducable build, we wanted to use the dependency system to supply a JAR containing the license to a plugin via the Locator.java approach (used by Clover, PMD and Checkstyle) supply the underlying tool API with the JAR extracted resource.

BUT as reporting plugins cant have <dependencies> we were trying to use the side effect of the fact (is this still a fact?) that if a plugin is already configured and in the 'runtime scope' of the build (ie it was declared in the <build><plugins> section of the POM but not bound to anything) then supposedly the <reporting> plugin MOJO will use that previously configured plugin, and thus find the <dependencies> defined in the <build><plugins><plugin><dependencies> section when searching for resources in it's configuration.

But it's not working and is causing me no end of frustration.

Can someone provide some forecasting as to whether this is

a) recognised as a serious omission from the model (that reporting plugins can not have <dependencies>)
b) it has been scheduled for a fix

What else can we do in the meantime?

Show
John Allen added a comment - This has become a complete show stopper for us. Is there no progress/thoughts/concern regarding this? Many plugins require licenses and other auxiliary files and, this being maven and about a reproducable build, we wanted to use the dependency system to supply a JAR containing the license to a plugin via the Locator.java approach (used by Clover, PMD and Checkstyle) supply the underlying tool API with the JAR extracted resource. BUT as reporting plugins cant have <dependencies> we were trying to use the side effect of the fact (is this still a fact?) that if a plugin is already configured and in the 'runtime scope' of the build (ie it was declared in the <build><plugins> section of the POM but not bound to anything) then supposedly the <reporting> plugin MOJO will use that previously configured plugin, and thus find the <dependencies> defined in the <build><plugins><plugin><dependencies> section when searching for resources in it's configuration. But it's not working and is causing me no end of frustration. Can someone provide some forecasting as to whether this is a) recognised as a serious omission from the model (that reporting plugins can not have <dependencies>) b) it has been scheduled for a fix What else can we do in the meantime?
Hide
Garvin LeClaire added a comment -

I am also interested in having a resolution to this.

Garvin Leclaire

Show
Garvin LeClaire added a comment - I am also interested in having a resolution to this. Garvin Leclaire
Hide
Pavel Muller added a comment -

I use the following approach and it works fine:

<build>
<extensions>
<extension>
<groupId>cz.aspectworks</groupId>
<artifactId>cz.aspectworks.build</artifactId>
<version>0.2.0</version>
</extension>
</extensions>
[SNIP]

I've got my PMD and checkstyle config files on classpath.

Show
Pavel Muller added a comment - I use the following approach and it works fine: <build> <extensions> <extension> <groupId>cz.aspectworks</groupId> <artifactId>cz.aspectworks.build</artifactId> <version>0.2.0</version> </extension> </extensions> [SNIP] I've got my PMD and checkstyle config files on classpath.
Hide
Arnaud Heritier added a comment -

As I said in MPMD-22 it's not a good idea to use extensions for that usecase.

Show
Arnaud Heritier added a comment - As I said in MPMD-22 it's not a good idea to use extensions for that usecase.

People

Vote (3)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: