You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Brett Porter (JIRA)" <ji...@codehaus.org> on 2005/05/04 03:03:19 UTC
[jira] Created: (MNG-366) revisit inclusion of reports in the plugin manager
revisit inclusion of reports in the plugin manager
--------------------------------------------------
Key: MNG-366
URL: http://jira.codehaus.org/browse/MNG-366
Project: m2
Type: Bug
Components: design
Versions: 2.0-alpha-2
Reporter: Brett Porter
Fix For: 2.0-alpha-3
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Reopened: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=all ]
Brett Porter reopened MNG-366:
------------------------------
reporting api is back in the core
> 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-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=all ]
Brett Porter updated MNG-366:
-----------------------------
Priority: Blocker (was: Major)
> 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
> Priority: Blocker
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=all ]
Brett Porter closed MNG-366:
----------------------------
Resolution: Fixed
done the separation. See MNG-469 for configuration issues.
> 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-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=all ]
Brett Porter updated MNG-366:
-----------------------------
Comment: was deleted
> 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-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=comments#action_39076 ]
Brett Porter commented on MNG-366:
----------------------------------
additional reporting requirement: ability to give a specific order to the listing of reports, or perhaps sort them.
> revisit inclusion of reports in the plugin manager
> --------------------------------------------------
>
> Key: MNG-366
> URL: http://jira.codehaus.org/browse/MNG-366
> Project: m2
> Type: Bug
> Components: design
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=comments#action_40689 ]
Brett Porter commented on MNG-366:
----------------------------------
more thoughts on how it should be configured:
- if in <reports> the configuration applies to the report, which may be different to the mojo in <build/> if the plugin is executed there. So we need that separate section.
- currently, the report is not configured at all, as we use a map lookup
- similar to executeMojo, a getReport method should get a configured MavenReport
- really, the site mojo is like another lifecycle executor in its role for hooking into the plugin manager and executing a report instead of a mojo. share commons code. It may actually be another lifecycle?
- also remove the MavenConfiguration inline with this, as above
<reports>
<plugins>
<plugin>
<g/a/v>
<configuration />
<report>
<id>mail-lists</id>
<configuration />
- how does this correlate to the new <executions/> element? Should also apply here, so a report can run twice with different configurations.
> 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-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=comments#action_40688 ]
Brett Porter commented on MNG-366:
----------------------------------
have moved the reports out of the core, however it has highlighted an issue that existed: we have no way of identifying exactly what reports a project wants to display (as one plugin may have >1 report).
We should leverage the fact that reports are mojos now.
> 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-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=comments#action_43093 ]
Brett Porter commented on MNG-366:
----------------------------------
also look into why components.xml is required for reporting plugins
> 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
> Priority: Blocker
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=comments#action_39061 ]
Brett Porter commented on MNG-366:
----------------------------------
needs more thought, but here is what we have come up with so far.
- it is ok for reports to be plugins, and probably loaded by the plugin manager
- should elminiate MavenConfiguration, this could be replaced with a single MavenProject instance, and we seem to be ok with allowing a dependency on thatas most reports will need it (eg dependency report should use it instead of the model to get transitive deps)
Issues:
- need to sort out how they are configured. Should the report objects reuse the mojo tools so become components with configuration also?
- need to check how configuration of the mojo overlaps with the report. I think the reporting parameters should mostly come from the <reports/> section, and anything in the plugins section just defines the execution parameters that wouldn't be specfied on the site itself.
- how is report inheritence defined? Would like consistency with plugins to support aggregation and inheritence, but pushing the config to the site.xml doesn't seem to allow inheritence at all. Needs to be looked at ni conjuction with site inheritence overall - perhaps the descriptor is made a resource and the pom refers to it using a URL/artifact identifier
> revisit inclusion of reports in the plugin manager
> --------------------------------------------------
>
> Key: MNG-366
> URL: http://jira.codehaus.org/browse/MNG-366
> Project: m2
> Type: Bug
> Components: design
> Versions: 2.0-alpha-2
> Reporter: Brett Porter
> Fix For: 2.0-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Closed: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=all ]
Brett Porter closed MNG-366:
----------------------------
Resolution: Fixed
> 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
> Priority: Blocker
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Updated: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
[jira] Commented: (MNG-366) revisit inclusion of reports in the plugin manager
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-366?page=comments#action_40643 ]
Brett Porter commented on MNG-366:
----------------------------------
outstanding:
- remove MavenReportConfiguration. AbstractMavenReport should have a outputDirectory and project field
- move the loading of the reports into the doxia mojo, out of the expression evaluator and core
- due to the way locales are done, this will moving the output directory creation into the abstract report where it can concat the locale
> 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-alpha-3
>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org