Vincent Siveton wrote:
Yep see for instance MJAVADOC-171
Based on some simple experiments on my machine, the fix for this is simply
to drop @aggregator; it's broken... (at least for reporting plugins that
fork lifecycles like javadoc, jxr and surefire), and its effect can be
easily simulate
We know that the documentation, specially the javadoc, is not perfect,
present or uptodate.
Well, I feared that ;-) My primary goal was to stress that it would be worth
the pain to maintain the javadoc right from the beginning (instead of fixing
bugs afterwards). From my personal experience, wri
Hi,
2008/2/6, Daniel Kulp <[EMAIL PROTECTED]>:
>
> Dan,
>
> I'm cannot really answer the question about what @aggregator does, but I
> can say the javadoc example is not a good one. There are many of us
> that think the javadoc mojo should NOT have it and have our javadoc
Agree. MJAVADOC-104 is
Hi,
2008/2/6, Benjamin Bentmann <[EMAIL PROTECTED]>:
> I apologize for this spam but I couldn't resist...
np. Comments are always welcome there!
> > what does the @aggregator annotation do, exactly?
>
> Doesn't this question illustrate a common symptom in Maven land, i.e. the
> lack of proper do
Stephen Connolly wrote:
I would have expected that there would be two javadoc mojo's something
like javadoc:javadoc which just generates the javadoc for the current
module, and javadoc:unified-javadoc which would be an @aggregator mojo that
produces the unified javadoc of all child modules.
Stuart McCulloch wrote:
On 07/02/2008, Dan Fabulich <[EMAIL PROTECTED]> wrote:
Based on preliminary research, I hypothesize that @aggregator is simply
broken so it's therefore not needed on any plugin, including javadoc.
hmm, well I use @aggregator on some local mojos and it seems to do
what
On 07/02/2008, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> Max Bowsher wrote:
>
> > Daniel Kulp wrote:
> >> Dan,
> >>
> >> I'm cannot really answer the question about what @aggregator does, but
> I
> >> can say the javadoc example is not a good one. There are many of us
> that
> >> think the java
My understanding is that this is all related to the work that is being done
on the build plan for 2.1.
AFAIK the idea behind @aggregator is that it specifies the mojo as being one
that operates on all child modules. So for example javadoc would want to do
this in order to provide a unified javadoc
Max Bowsher wrote:
Daniel Kulp wrote:
Dan,
I'm cannot really answer the question about what @aggregator does, but I
can say the javadoc example is not a good one. There are many of us that
think the javadoc mojo should NOT have it and have our javadoc plugins
locked down to a previous ver
Daniel Kulp wrote:
Dan,
I'm cannot really answer the question about what @aggregator does, but I
can say the javadoc example is not a good one. There are many of us
that think the javadoc mojo should NOT have it and have our javadoc
plugins locked down to a previous version for the same rea
I apologize for this spam but I couldn't resist...
what does the @aggregator annotation do, exactly?
Doesn't this question illustrate a common symptom in Maven land, i.e. the
lack of proper documentation, just too well?
Specifically, in 2.4 I added @aggregator to the surefire-report plugin
w
Dan,
I'm cannot really answer the question about what @aggregator does, but I
can say the javadoc example is not a good one. There are many of us
that think the javadoc mojo should NOT have it and have our javadoc
plugins locked down to a previous version for the same reason. With
@aggreg
Dumb question (possibly): what does the @aggregator annotation do,
exactly?
I read the doc here:
http://maven.apache.org/developers/mojo-api-specification.html
It says: "Flags this Mojo to run it in a multi module way, i.e. aggregate
the build with the set of projects listed as modules."
B
13 matches
Mail list logo
