[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
