Ok ...
You're right, we are talking about the same thing in the end ... :-)
In order to summarise :
- we both agree that this is currently not implemented
- we both agree that the best approach is a push one (i.e. plugins drop
generated doc in a pre-defined location)
- I agree with with you that plugin.xml is the best way to go (but is
not there yet, right ?)
- I agree with maven.gen.docs and maven.dest.docs
So we're 100% in agreement. Cool.
Let's do it !
Meanwhile I have refactored the Clover plugin and it now completely
separate from the other plugins and there is no modification to the
existing plugins apart from sites.dvsl, in which I have added :
#if
($context.toolbox.fileutil.file("$context.toolbox.docDest/clover").exist
s())
<div><small><a href="$relativePath/clover/index.html">Clover Test
Coverage</a></small></div>
#end
and that should go when we have a sites.dvsl which builds the link for
reports from looping in maven.dest.docs, right ?
I'm also trying to figure out what is the condition I should put in
maven-reports.xml to conditionally describe the Clover plugin report but
I can't find where this file is processed and I don't know which
variable I can use to write the condition. Where do "$project.build.*"
variables come from ?
I'm going to commit the Clover plugin soon (unless someone says no) as
it is now very much separated from the core Maven and a Quilt plugin can
be added with no interference.
It adds one delegator called "maven:clover-report" which does it all and
generates clover doc in maven.dest.docs/clover.
Thanks
-Vincent
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 16 June 2002 14:00
> To: Turbine Maven Developers List
> Subject: RE: New Clover plugin
>
> 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'" <turbine-maven-
> [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: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]>
