Nope,
I understood what you meant, AFAIK.
My point was that the detail about the reports that a plugin produces
should be held in the plugin's configuration - plugin.xml as described in
the tasks document. The docs target should get the complete list of
reports to be produced from maven when it scans for installed plugins.
If the plugin was to produce xdocs, I'd expect those to go to
${maven.gen.docs}. If it was html directly, I'd expect that to be placed
in ${maven.dest.docs}
Am I missing something?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
"Vincent Massol" <[EMAIL PROTECTED]>
06/16/02 09:55 PM
Please respond to "Turbine Maven Developers List"
To: "'Turbine Maven Developers List'"
<[EMAIL PROTECTED]>
cc:
Subject: RE: New Clover plugin
dIon,
I still feel we are talking cross-purpose :-)
What I mean is that I have had to *modify* sites.dvsl and
maven-reports.xml to include Clover on the generated web site as they
are *not* written in a generic way (it is a set of "if").
The proposal below was to make them generic so that plugin
reports can be plugged seamlessly.
Hope it is more clear.
Thanks
-Vincent
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 16 June 2002 12:55
> To: Turbine Maven Developers List
> Subject: RE: New Clover plugin
>
> Hi Vincent, some answers, questions etc :)
>
> > - provide a location (maven.doc.plugin.destDir for example) where
> > plugins can generate their reports
> Is this different from maven.gen.docs and maven.docs.dest that already
> exist?
> > - the doc plugin will loop on all the directories located in
> > maven.doc.plugin.destDir and add them to the "Maven Reports" menu
> I'd much rather this sort of info was in plugin.xml, e.g. what extra
does
> a plugin add? Targets to the build, reports etc, should all be in the
> plugins config.
>
> > - the doc plugin can also look for a description of the report
generated
> > by the plugin in its metainfo. Or simply look for a
> >
${maven.doc.plugin.DestDir}/<pluginreportname>/report-description.xml
> > file to be included in maven-reports.xml
> See above
>
> > What we need is the ability to add a plugin without interfering _at
all_
> > with existing plugins (i.e. not to have to modify them to make the
new
> > plugin work).
> That is the intent of whats in tasks.xml. Dynamic discovery and
processing
> of plugins.
>
> > For example the clover plugin should be able to be dropped in the
plugin
> > directory and work directly as is. I should be able to have a quilt
> > plugin that work in the same way.
> That's the intent of what we documented.
>
> > Is that more clear ?
> Yes, but it seems like we didn't explain the plugins discussion we had
a
> week ago too well. I'm happy to continue this in email so more people
can
> comment. The last discussion was done in IRC, IIRC :)
>
> --
> dIon Gillard, Multitask Consulting
> Work: http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
>
>
>
>
> "Vincent Massol" <[EMAIL PROTECTED]>
> 06/16/02 09:18 PM
> Please respond to "Turbine Maven Developers List"
>
>
> To: "'Turbine Maven Developers List'" <turbine-maven-
> [EMAIL PROTECTED]>
> cc:
> Subject: RE: New Clover plugin
>
>
> dIon,
>
> I have probably missed the discussion but I've read agin the task list
> and I don't see any hint of what I describe below ...
>
> For example, here is what I would imagine for the doc plugin :
>
> - provide a location (maven.doc.plugin.destDir for example) where
> plugins can generate their reports
> - the doc plugin will loop on all the directories located in
> maven.doc.plugin.destDir and add them to the "Maven Reports" menu
> - the doc plugin can also look for a description of the report
generated
> by the plugin in its metainfo. Or simply look for a
> ${maven.doc.plugin.DestDir}/<pluginreportname>/report-description.xml
> file to be included in maven-reports.xml
>
> What we need is the ability to add a plugin without interfering _at
all_
> with existing plugins (i.e. not to have to modify them to make the new
> plugin work).
>
> For example the clover plugin should be able to be dropped in the
plugin
> directory and work directly as is. I should be able to have a quilt
> plugin that work in the same way.
>
> Is that more clear ?
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 16 June 2002 04:48
> > To: Turbine Maven Developers List
> > Subject: RE: New Clover plugin
> >
> > I hate to say this, but we've had this discussion several times over
> the
> > last few weeks....and documented what the outcome was at:
> >
> > http://jakarta.apache.org/turbine/maven/tasks.html
> >
> > Care to add more to what's there, or discuss it here?
> > --
> > dIon Gillard, Multitask Consulting
> > Work: http://www.multitask.com.au
> > Developers: http://adslgateway.multitask.com.au/developers
> >
> >
> >
> >
> > "Vincent Massol" <[EMAIL PROTECTED]>
> > 06/16/02 05:26 AM
> > Please respond to "Turbine Maven Developers List"
> >
> >
> > To: "'Turbine Maven Developers List'" <turbine-maven-
> > [EMAIL PROTECTED]>
> > cc:
> > Subject: RE: New Clover plugin
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: bob mcwhirter [mailto:[EMAIL PROTECTED]]
> > > Sent: 15 June 2002 20:24
> > > To: Turbine Maven Developers List
> > > Subject: RE: New Clover plugin
> > >
> > > > We are almost there with callbacks and maven-ng but not
> completely.
> > Is
> > > > it possible in maven-ng to completely replace a target from one
> > plugin
> > > > and then this new target can be used seamlessly by other plugins
?
> > >
> > > Yah, I think we could do that...
> > >
> > > We're in control, now, with maven-ng, so more things are possible.
> > >
> >
> > That means that we really need to define a contract for plugins. For
> > example for the moment we have a centralized plugin for the
> > documentation. That won't be possible anymore. Each plugin must be
> able
> > to get a hook to publish its own reports for the web site, etc.
> >
> > We need to rethink completely what a plugin is, I believe.
> >
> > -Vincent
> >
> >
> > > -bob
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> > > [EMAIL PROTECTED]>
> > > For additional commands, e-mail: <mailto:turbine-maven-dev-
> > > [EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> > [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:turbine-maven-dev-
> > [EMAIL PROTECTED]>
> >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> > [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:turbine-maven-dev-
> > [EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-maven-dev-
> [EMAIL PROTECTED]>
>
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:turbine-maven-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:turbine-maven-dev-
> [EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
