[MNG-366] revisit inclusion of reports in the plugin manager

• Type: Bug
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 2.0-alpha-2
• Fix Version/s: 2.0-beta-1
• Component/s: Design, Patterns & Best Practices
• Assignee: Brett Porter
• Reporter: Brett Porter
• Created: 03/May/05 20:03
• Updated: 01/Feb/06 14:43
• Resolved: 21/Jul/05 01:48

Description

We've so far included the reports directly into the plugin manager - so reports are plugins. This was done to reduce duplication, and to make it easier to create plugins that do both tasks (Eg clover doing a report, but also a test that fails if under a certain threshold).

The downsides are:

• doxia is now loaded into the core
• this might make it harder to reuse from Ant tasks
• it is inconsistent with the POM definition, and a report may need to be declared twice unnecessarily.

We need to revisit whether this was the right choice - and if so, whether separating build from report plugins in the pom is the best idea.

Doxia being loaded into the core could definitely be avoided by correct plugin classloader handling.

Original mail before decision:

Firstly, are report JARs regular plugins, or should they have the type
"maven-report"? We believe they should be one JAR - ie only a
maven-plugin type.

• On the upside, this means that when you have a goal and a report doing
  similar things (eg the clover test that fails if a certain coverage % is
  missed, as well as the generated report), the code is all together and
  there are just a mojo and report class in the JAR.
• On the downside, you are incurring a maven-plugin-api dependency on
  someone only doing reporting, and a maven-reporting-api dependency on
  someone only doing a plugin when the JAR provides both. I don't believe
  this is a big deal. An alternative is to have the reporting mojo in a
  separate jar that depends on the mojo, overcoming the latter which is
  probably the only real problem. Thoughts?

Now, currently the report manager is a separate entity, used by the site
plugin. It resolves the reports on demand, similarly to the plugin
manager. If a report is a plugin, should the single plugin manager be
used? I think that it probably should, but we can defer the work on this
until we are certain.

Also, I think we need to introduce a pluginManagement section to
<reports /> so that report plugin configuration can be done in the same
way as build plugin configuration. Does everyone agree?

Issue Links

• is related to: MNG-469 implement report configuration