jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
Signup
Maven 2.x and 3.x Site Plugin
  • Maven 2.x and 3.x Site Plugin
  • MSITE-443

add a reportingManagement section

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 3.0
  • Component/s: None
  • Labels:
    None
  • Environment:
    maven-site-plugin 2.0-beta-3-SNAPSHOT
  • Number of attachments :
    0

Description

Consider the following POM:

<!-- ... ... -->
<!-- ... ... -->
<build>
    <pluginManagement>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <configuration>
            <author>false</author>
            </configuration>
        </plugin>
    </pluginManagement>
</build>
<!-- ... ... -->
<!-- ... ... -->
<reporting>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
        </plugin>
    </plugins>
</reporting>
<!-- ... ... -->

mvn site:site doesn't honor the javadoc configuration specified in the <pluginManagement/> section.
However, mvn javadoc:javadoc honors them.

This is true not just for javadoc but other plugins like checkstyle as well.

I guess, the <reporting/> section doesn't use the <pluginManagement/> section at all.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-3385 PluginManagement does not work for report-plugins

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Improvement - An improvement or enhancement to an existing feature or task. MSITE-444 reporting section should allow additional dependencies in plugins as well

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. MSITE-516 reportPlugins should/could inherit more information from pluginManagement

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

Improvement - An improvement or enhancement to an existing feature or task. MSITE-523 Configuring build and reporting goals (under reportPlugins) requires duplication

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. MNG-2578 Make it possible to set default versions for reporting-plugins (i.e. plugins under <reporting>)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Indrajit Raychaudhuri added a comment - 16/Dec/05 9:01 AM

This might be related to MNG-1855 but it has been raised for checkstyle-plugin module. It's true for other plugins as well.

Show
Indrajit Raychaudhuri added a comment - 16/Dec/05 9:01 AM This might be related to MNG-1855 but it has been raised for checkstyle-plugin module. It's true for other plugins as well.
Hide
Permalink
Brett Porter added a comment - 19/Dec/05 12:40 AM

not really related to mng-1855

Show
Brett Porter added a comment - 19/Dec/05 12:40 AM not really related to mng-1855
Hide
Permalink
Brett Porter added a comment - 19/Dec/05 12:41 AM

this is a design issue... do we need a reportingManagement element?

Show
Brett Porter added a comment - 19/Dec/05 12:41 AM this is a design issue... do we need a reportingManagement element?
Hide
Permalink
Indrajit Raychaudhuri added a comment - 19/Dec/05 2:13 AM

Is there a way to make site reporting honor plugin config in <build/>?

We can have a <reportingManagement/> element to config reporting as such.
But then we would land up in a situation where certain configurations have to be repeated in <pluginManagement/> as well as <reportingManagement/>.

The solution would serve the purpose but won't be as elegent

Show
Indrajit Raychaudhuri added a comment - 19/Dec/05 2:13 AM Is there a way to make site reporting honor plugin config in <build/>? We can have a <reportingManagement/> element to config reporting as such. But then we would land up in a situation where certain configurations have to be repeated in <pluginManagement/> as well as <reportingManagement/>. The solution would serve the purpose but won't be as elegent
Hide
Permalink
Brett Porter added a comment - 19/Dec/05 4:18 PM

It's intentionally the other way around.

settings in reporting are already applied to build plugins so they don't need to be duplicated, but build plugins have a more honerous requirement - specifically they will often fail the build when the reporting plugin won't during site generation. For this reason, build configuration is not passed to the reports.

Show
Brett Porter added a comment - 19/Dec/05 4:18 PM It's intentionally the other way around. settings in reporting are already applied to build plugins so they don't need to be duplicated, but build plugins have a more honerous requirement - specifically they will often fail the build when the reporting plugin won't during site generation. For this reason, build configuration is not passed to the reports.
Hide
Permalink
Indrajit Raychaudhuri added a comment - 20/Dec/05 1:57 AM

Wonderful!

So the <reportingManagement/> idea in action_53690 actually makes sense to me now and appears clean enough too.

This also appears to be a candidate for docu. somewhere (maybe in maven-model) specifying the distinction between <build><pluginManagement/></build> and <reportingManagement/> and what should go where (as part of best-practice).

Show
Indrajit Raychaudhuri added a comment - 20/Dec/05 1:57 AM Wonderful! So the <reportingManagement/> idea in action_53690 actually makes sense to me now and appears clean enough too. This also appears to be a candidate for docu. somewhere (maybe in maven-model) specifying the distinction between <build><pluginManagement/></build> and <reportingManagement/> and what should go where (as part of best-practice).
Hide
Permalink
John Allen added a comment - 13/Feb/06 10:53 AM

Any thoughts re moving this up the priority ladder? After all one of the key benefits of using maven is the reduction in duplicated configs and currently I am not able to share any of my reporting settings across projects.

Additionally re reporting plugin configs affecting build plugin settings.

I uses a number of plugins for both reporting and compliance/governance checks, currently javadoc warnings, pmd, checkstyle and test coverage. I would like to be able to run reporting against one set of configs and have build uses others. Ie. reporting tends to use quite a harsh set of rules for PMD/Checkstyle whereas my compliance build (which fails the build if a governance setting is not met) uses a more relxed config. How can i achieve this separation on configs for plugins that are used in both reporting and build?

Show
John Allen added a comment - 13/Feb/06 10:53 AM Any thoughts re moving this up the priority ladder? After all one of the key benefits of using maven is the reduction in duplicated configs and currently I am not able to share any of my reporting settings across projects. Additionally re reporting plugin configs affecting build plugin settings. I uses a number of plugins for both reporting and compliance/governance checks, currently javadoc warnings, pmd, checkstyle and test coverage. I would like to be able to run reporting against one set of configs and have build uses others. Ie. reporting tends to use quite a harsh set of rules for PMD/Checkstyle whereas my compliance build (which fails the build if a governance setting is not met) uses a more relxed config. How can i achieve this separation on configs for plugins that are used in both reporting and build?
Hide
Permalink
Brett Porter added a comment - 15/Feb/06 3:19 AM

this is as high up the priority ladder as it goes. no pom additions until 2.1, sorry.

Show
Brett Porter added a comment - 15/Feb/06 3:19 AM this is as high up the priority ladder as it goes. no pom additions until 2.1, sorry.
Hide
Permalink
Denis Cabasson added a comment - 12/May/06 8:45 AM

In relation with MNG-1855:

when using a report plugin needing a dependency (
checkstyle, set as in:
http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html, ont sure this example is working, but no time to test it, sorry.)

extra jars need to be added to classpath. It's not possible right now, cause report part has no dependencies child.

Maybe plan to add this to reportManagement?

Show
Denis Cabasson added a comment - 12/May/06 8:45 AM In relation with MNG-1855: when using a report plugin needing a dependency ( checkstyle, set as in: http://maven.apache.org/plugins/maven-checkstyle-plugin/tips.html , ont sure this example is working, but no time to test it, sorry.) extra jars need to be added to classpath. It's not possible right now, cause report part has no dependencies child. Maybe plan to add this to reportManagement?
Hide
Permalink
Rory Winston added a comment - 27/Mar/09 7:58 AM

It would be nice to be able to add custom taglets to a classpath used just for reporting, for instance

Show
Rory Winston added a comment - 27/Mar/09 7:58 AM It would be nice to be able to add custom taglets to a classpath used just for reporting, for instance
Hide
Permalink
Thomas Demande added a comment - 13/Nov/09 4:57 AM

Quite painful in combination with MJAVADOC-268, where it's needed to be able to force a version.

Show
Thomas Demande added a comment - 13/Nov/09 4:57 AM Quite painful in combination with MJAVADOC-268 , where it's needed to be able to force a version.
Hide
Permalink
Jason van Zyl added a comment - 28/Dec/09 7:05 PM

Now the site plugin's use case.

Show
Jason van Zyl added a comment - 28/Dec/09 7:05 PM Now the site plugin's use case.
Hide
Permalink
Dennis Lundberg added a comment - 29/Dec/09 4:05 AM

Jason,

If this the issue of moving all reporting plugins configuration into the Site Plugin? Is this a requirement for Maven 3? Would it be possible to make this work for Maven 2.1+ as well?

Show
Dennis Lundberg added a comment - 29/Dec/09 4:05 AM Jason, If this the issue of moving all reporting plugins configuration into the Site Plugin? Is this a requirement for Maven 3? Would it be possible to make this work for Maven 2.1+ as well?
Hide
Permalink
Sven Ludwig added a comment - 03/Feb/10 6:21 PM

I want to add an idea how to solve this issue. It could be done by offering a new boolean property in the reporting section like "honorPluginManagement". Default should be false, but if it is set to true, the plugins in the reporting section would use the respective configurations in pluginManagement. It should then also be possible to override pluginManagement settings in the reporting section. Moreover, it should work no matter if the reporting section is in the same pom as the pluginManagement section, or if it is further down the inheritance tree. At least from my current personal perspective, this would be a good solution.

I can see however that some people may want a separate pluginManagement-like section within the reporting section.

Show
Sven Ludwig added a comment - 03/Feb/10 6:21 PM I want to add an idea how to solve this issue. It could be done by offering a new boolean property in the reporting section like "honorPluginManagement". Default should be false, but if it is set to true, the plugins in the reporting section would use the respective configurations in pluginManagement. It should then also be possible to override pluginManagement settings in the reporting section. Moreover, it should work no matter if the reporting section is in the same pom as the pluginManagement section, or if it is further down the inheritance tree. At least from my current personal perspective, this would be a good solution. I can see however that some people may want a separate pluginManagement-like section within the reporting section.
Hide
Permalink
Anthony Whitford added a comment - 31/Jul/11 7:57 AM

I like Sven's idea. Ultimately, I am looking for a way to say, "Use javadoc 2.8" once – this should affect both the <build> and <reporting> sections, otherwise my pom violates the DRY principle.

Show
Anthony Whitford added a comment - 31/Jul/11 7:57 AM I like Sven's idea. Ultimately, I am looking for a way to say, "Use javadoc 2.8" once – this should affect both the <build> and <reporting> sections, otherwise my pom violates the DRY principle.
Hide
Permalink
Diwaker Gupta added a comment - 24/Aug/12 12:37 PM

This major bug has been open for 7 years now. There seems be enough community support for this feature. The Maven developers should either mark this as won't fix or fix it for real, rather than let it linger in limbo forever.

Show
Diwaker Gupta added a comment - 24/Aug/12 12:37 PM This major bug has been open for 7 years now. There seems be enough community support for this feature. The Maven developers should either mark this as won't fix or fix it for real, rather than let it linger in limbo forever.
Hide
Permalink
Herve Boutemy added a comment - 16/Sep/12 10:04 AM

this is fixed in Maven 3 + maven-site-plugin-3

see explanations

Show
Herve Boutemy added a comment - 16/Sep/12 10:04 AM this is fixed in Maven 3 + maven-site-plugin-3 see explanations
Hide
Permalink
Jin Kwon added a comment - 18/Sep/12 7:59 AM - edited

I just find that maven-site-plugin seems have some problem although works as explained on http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution.

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>2.8.1</version>                                 <----------------| must follow the lights; it doesn't.              
      </plugin>                                                                   |
      <plugin>                                                                    |
        <artifactId>maven-site-plugin</artifactId>                                |
        <version>3.1</version>                                                    |
      </plugin>                                                                   |
    </plugins>                                                                    |
  </pluginManagement>                                                             |
  <plugins>                                                                       |
    <plugin>                                                                      |
      <artifactId>maven-javadoc-plugin</artifactId> <------------| 2.7 -----------|
    </plugin>                                                    |
    <plugin>                                                     |
      <groupId>org.apache.maven.plugins</groupId>                |
      <artifactId>maven-site-plugin</artifactId>                 |
      <executions>                                               |
        <execution>                                              |
          <id>attach-descriptor</id>                             |
          <goals>                                                |
            <goal>attach-descriptor</goal>                       |
          </goals>                                               |
        </execution>                                             |
      </executions>                                              |
      <configuration>                                            |
        <reportPlugins>                                          |
          <plugin>                                               |
            <artifactId>maven-javadoc-plugin</artifactId> -------|
          </plugin>
        </reportPlugins>
      </configuration>
    <plugin>
  </plugins>
</build>
Show
Jin Kwon added a comment - 18/Sep/12 7:59 AM - edited I just find that maven-site-plugin seems have some problem although works as explained on http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resolution . <build> <pluginManagement> <plugins> <plugin> <artifactId>maven-javadoc-plugin</artifactId> <version>2.8.1</version> <----------------| must follow the lights; it doesn't. </plugin> | <plugin> | <artifactId>maven-site-plugin</artifactId> | <version>3.1</version> | </plugin> | </plugins> | </pluginManagement> | <plugins> | <plugin> | <artifactId>maven-javadoc-plugin</artifactId> <------------| 2.7 -----------| </plugin> | <plugin> | <groupId>org.apache.maven.plugins</groupId> | <artifactId>maven-site-plugin</artifactId> | <executions> | <execution> | <id>attach-descriptor</id> | <goals> | <goal>attach-descriptor</goal> | </goals> | </execution> | </executions> | <configuration> | <reportPlugins> | <plugin> | <artifactId>maven-javadoc-plugin</artifactId> -------| </plugin> </reportPlugins> </configuration> <plugin> </plugins> </build>

People

  • Assignee:
    Unassigned
    Reporter:
    Indrajit Raychaudhuri
Vote (86)
Watch (82)

Dates

  • Created:
    16/Dec/05 8:58 AM
    Updated:
    18/Sep/12 8:41 AM
    Resolved:
    16/Sep/12 10:04 AM
  • Atlassian JIRA (v5.2.7#850-sha1:b2af0c8)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.