[ http://jira.codehaus.org/browse/MNG-366?page=all ]
Brett Porter updated MNG-366:
-----------------------------
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?
was:
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?
Fix Version: (was: 2.0-alpha-3)
2.0-beta-1
Environment:
> revisit inclusion of reports in the plugin manager
> --------------------------------------------------
>
> Key: MNG-366
> URL: http://jira.codehaus.org/browse/MNG-366
> Project: Maven 2
> Type: Bug
> Components: design
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Assignee: Brett Porter
> Fix For: 2.0-beta-1
>
>
> 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?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
