opinions on MJAVADOC-451

[Richard Sand]

Hi all,

I'd like to ask for opinions on 
https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and I 
have been discussing this off list and essentially disagree on it.


The request is very simple - to add a "skip" parameter to the 
javadoc:fix goal. In my projects we are using the fix goal unattended, 
i.e. with the parameter "force=true", as part of the regular build 
lifecycle.


Most goals (including javadoc) that run in the regular lifecycle have a 
skip option. Robert's position (and forgive me if I misrepresent this at 
all Robert and please weigh in) is that javadoc:fix should not be used 
in the lifecycle and that the goal should in fact have 
requireDirectInvocation=true. He also pointed out to me that I can 
create a profile to enable/disable the goal as an alternative.


My opinion is that, since the goal does not require direct invocation, 
then running within the lifecycle has to be considered acceptable use of 
the goal. And having a skip parameter adds 5 lines of code, is a common 
and normal pattern used by many other plugins/goals, and allows the goal 
to be used in this fashion without introducing even more profiles.


I've submitted patches for this issue and also several other issues in 
the javadoc plugin as I continue to work through getting the goal to 
work well automated. Just pointing out that I'm not just asking for the 
larger community to do stuff to make my life easier - I'm trying to 
contribute as best I can and provide patches for what I uncover.


Best regards,

Richard

Re: opinions on MJAVADOC-451

[Richard Sand]

Anyone want to give this a quick read/opinion? :-)

-Richard

-- Original Message --

From: "Richard Sand" 
To: dev@maven.apache.org
Sent: 8/1/2016 6:33:30 PM
Subject: opinions on MJAVADOC-451


Hi all,

I'd like to ask for opinions on 
https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and 
I have been discussing this off list and essentially disagree on it.


The request is very simple - to add a "skip" parameter to the 
javadoc:fix goal. In my projects we are using the fix goal unattended, 
i.e. with the parameter "force=true", as part of the regular build 
lifecycle.


Most goals (including javadoc) that run in the regular lifecycle have a 
skip option. Robert's position (and forgive me if I misrepresent this 
at all Robert and please weigh in) is that javadoc:fix should not be 
used in the lifecycle and that the goal should in fact have 
requireDirectInvocation=true. He also pointed out to me that I can 
create a profile to enable/disable the goal as an alternative.


My opinion is that, since the goal does not require direct invocation, 
then running within the lifecycle has to be considered acceptable use 
of the goal. And having a skip parameter adds 5 lines of code, is a 
common and normal pattern used by many other plugins/goals, and allows 
the goal to be used in this fashion without introducing even more 
profiles.


I've submitted patches for this issue and also several other issues in 
the javadoc plugin as I continue to work through getting the goal to 
work well automated. Just pointing out that I'm not just asking for the 
larger community to do stuff to make my life easier - I'm trying to 
contribute as best I can and provide patches for what I uncover.


Best regards,

Richard

Re: opinions on MJAVADOC-451

[Christopher]

I'm always in favor of adding skip properties. They are very useful for
manipulating builds for debugging, running on CI servers, controlling
executions in child poms, etc. Even if it's not recommended to run
unattended, it's still possible, so a skip option is useful.

On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:

> Anyone want to give this a quick read/opinion? :-)
>
> -Richard
>
> -- Original Message --
>
> From: "Richard Sand" 
> To: dev@maven.apache.org
> Sent: 8/1/2016 6:33:30 PM
> Subject: opinions on MJAVADOC-451
>
> >Hi all,
> >
> >I'd like to ask for opinions on
> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
> >I have been discussing this off list and essentially disagree on it.
> >
> >The request is very simple - to add a "skip" parameter to the
> >javadoc:fix goal. In my projects we are using the fix goal unattended,
> >i.e. with the parameter "force=true", as part of the regular build
> >lifecycle.
> >
> >Most goals (including javadoc) that run in the regular lifecycle have a
> >skip option. Robert's position (and forgive me if I misrepresent this
> >at all Robert and please weigh in) is that javadoc:fix should not be
> >used in the lifecycle and that the goal should in fact have
> >requireDirectInvocation=true. He also pointed out to me that I can
> >create a profile to enable/disable the goal as an alternative.
> >
> >My opinion is that, since the goal does not require direct invocation,
> >then running within the lifecycle has to be considered acceptable use
> >of the goal. And having a skip parameter adds 5 lines of code, is a
> >common and normal pattern used by many other plugins/goals, and allows
> >the goal to be used in this fashion without introducing even more
> >profiles.
> >
> >I've submitted patches for this issue and also several other issues in
> >the javadoc plugin as I continue to work through getting the goal to
> >work well automated. Just pointing out that I'm not just asking for the
> >larger community to do stuff to make my life easier - I'm trying to
> >contribute as best I can and provide patches for what I uncover.
> >
> >Best regards,
> >
> >Richard
> >
> >

Re: opinions on MJAVADOC-451

[Benson Margulies]

On Fri, Aug 5, 2016 at 10:37 AM, Christopher  wrote:
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possible, so a skip option is useful.

Me too.  I don't see the point about arguing that some goal 'doesn't
belong in a lifecycle'. We can't predict what people will find useful.

>
> On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
>
>> Anyone want to give this a quick read/opinion? :-)
>>
>> -Richard
>>
>> -- Original Message --
>>
>> From: "Richard Sand" 
>> To: dev@maven.apache.org
>> Sent: 8/1/2016 6:33:30 PM
>> Subject: opinions on MJAVADOC-451
>>
>> >Hi all,
>> >
>> >I'd like to ask for opinions on
>> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
>> >I have been discussing this off list and essentially disagree on it.
>> >
>> >The request is very simple - to add a "skip" parameter to the
>> >javadoc:fix goal. In my projects we are using the fix goal unattended,
>> >i.e. with the parameter "force=true", as part of the regular build
>> >lifecycle.
>> >
>> >Most goals (including javadoc) that run in the regular lifecycle have a
>> >skip option. Robert's position (and forgive me if I misrepresent this
>> >at all Robert and please weigh in) is that javadoc:fix should not be
>> >used in the lifecycle and that the goal should in fact have
>> >requireDirectInvocation=true. He also pointed out to me that I can
>> >create a profile to enable/disable the goal as an alternative.
>> >
>> >My opinion is that, since the goal does not require direct invocation,
>> >then running within the lifecycle has to be considered acceptable use
>> >of the goal. And having a skip parameter adds 5 lines of code, is a
>> >common and normal pattern used by many other plugins/goals, and allows
>> >the goal to be used in this fashion without introducing even more
>> >profiles.
>> >
>> >I've submitted patches for this issue and also several other issues in
>> >the javadoc plugin as I continue to work through getting the goal to
>> >work well automated. Just pointing out that I'm not just asking for the
>> >larger community to do stuff to make my life easier - I'm trying to
>> >contribute as best I can and provide patches for what I uncover.
>> >
>> >Best regards,
>> >
>> >Richard
>> >
>> >

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: opinions on MJAVADOC-451

[Gary Gregory]

On Aug 5, 2016 7:41 AM, "Benson Margulies"  wrote:
>
> On Fri, Aug 5, 2016 at 10:37 AM, Christopher  wrote:
> > I'm always in favor of adding skip properties. They are very useful for
> > manipulating builds for debugging, running on CI servers, controlling
> > executions in child poms, etc. Even if it's not recommended to run
> > unattended, it's still possible, so a skip option is useful.
>
> Me too.  I don't see the point about arguing that some goal 'doesn't
> belong in a lifecycle'. We can't predict what people will find useful.

Why not add the ability to skip various (named) activities to maven itself?

Gary
>
> >
> > On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
> >
> >> Anyone want to give this a quick read/opinion? :-)
> >>
> >> -Richard
> >>
> >> ------ Original Message --
> >>
> >> From: "Richard Sand" 
> >> To: dev@maven.apache.org
> >> Sent: 8/1/2016 6:33:30 PM
> >> Subject: opinions on MJAVADOC-451
> >>
> >> >Hi all,
> >> >
> >> >I'd like to ask for opinions on
> >> >https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
> >> >I have been discussing this off list and essentially disagree on it.
> >> >
> >> >The request is very simple - to add a "skip" parameter to the
> >> >javadoc:fix goal. In my projects we are using the fix goal unattended,
> >> >i.e. with the parameter "force=true", as part of the regular build
> >> >lifecycle.
> >> >
> >> >Most goals (including javadoc) that run in the regular lifecycle have
a
> >> >skip option. Robert's position (and forgive me if I misrepresent this
> >> >at all Robert and please weigh in) is that javadoc:fix should not be
> >> >used in the lifecycle and that the goal should in fact have
> >> >requireDirectInvocation=true. He also pointed out to me that I can
> >> >create a profile to enable/disable the goal as an alternative.
> >> >
> >> >My opinion is that, since the goal does not require direct invocation,
> >> >then running within the lifecycle has to be considered acceptable use
> >> >of the goal. And having a skip parameter adds 5 lines of code, is a
> >> >common and normal pattern used by many other plugins/goals, and allows
> >> >the goal to be used in this fashion without introducing even more
> >> >profiles.
> >> >
> >> >I've submitted patches for this issue and also several other issues in
> >> >the javadoc plugin as I continue to work through getting the goal to
> >> >work well automated. Just pointing out that I'm not just asking for
the
> >> >larger community to do stuff to make my life easier - I'm trying to
> >> >contribute as best I can and provide patches for what I uncover.
> >> >
> >> >Best regards,
> >> >
> >> >Richard
> >> >
> >> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

Re: opinions on MJAVADOC-451

[Christopher]

On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory  wrote:

> On Aug 5, 2016 7:41 AM, "Benson Margulies"  wrote:
> >
> > On Fri, Aug 5, 2016 at 10:37 AM, Christopher 
> wrote:
> > > I'm always in favor of adding skip properties. They are very useful for
> > > manipulating builds for debugging, running on CI servers, controlling
> > > executions in child poms, etc. Even if it's not recommended to run
> > > unattended, it's still possible, so a skip option is useful.
> >
> > Me too.  I don't see the point about arguing that some goal 'doesn't
> > belong in a lifecycle'. We can't predict what people will find useful.
>
> Why not add the ability to skip various (named) activities to maven itself?
>

That exists. It's called profiles... but it's very verbose in the POM. It's
much more pleasant to work with if the behavior of the individual plugin is
flexible through configuration.

A feature could be added to Maven to skip specific named executions of
plugins, I suppose... but that sounds like a feature that would require
some discussion and debate before showing up in some future version of
Maven. The proposal is something which could be done today, which would
work, regardless of the version of Maven you're using, and which is
consistent with similar configurable behavior in countless existing plugins.

Re: opinions on MJAVADOC-451

[Richard Sand]

What about putting the skip option into an abstract base plugin class? Just 
thinking out loud

Sent from my iPhone

> On Aug 5, 2016, at 6:51 PM, Christopher  wrote:
> 
>> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory  wrote:
>> 
>>> On Aug 5, 2016 7:41 AM, "Benson Margulies"  wrote:
>>> 
>>> On Fri, Aug 5, 2016 at 10:37 AM, Christopher 
>> wrote:
 I'm always in favor of adding skip properties. They are very useful for
 manipulating builds for debugging, running on CI servers, controlling
 executions in child poms, etc. Even if it's not recommended to run
 unattended, it's still possible, so a skip option is useful.
>>> 
>>> Me too.  I don't see the point about arguing that some goal 'doesn't
>>> belong in a lifecycle'. We can't predict what people will find useful.
>> 
>> Why not add the ability to skip various (named) activities to maven itself?
> 
> That exists. It's called profiles... but it's very verbose in the POM. It's
> much more pleasant to work with if the behavior of the individual plugin is
> flexible through configuration.
> 
> A feature could be added to Maven to skip specific named executions of
> plugins, I suppose... but that sounds like a feature that would require
> some discussion and debate before showing up in some future version of
> Maven. The proposal is something which could be done today, which would
> work, regardless of the version of Maven you're using, and which is
> consistent with similar configurable behavior in countless existing plugins.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: opinions on MJAVADOC-451

[Gary Gregory]

On Fri, Aug 5, 2016 at 3:51 PM, Christopher  wrote:

> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory 
> wrote:
>
> > On Aug 5, 2016 7:41 AM, "Benson Margulies" 
> wrote:
> > >
> > > On Fri, Aug 5, 2016 at 10:37 AM, Christopher 
> > wrote:
> > > > I'm always in favor of adding skip properties. They are very useful
> for
> > > > manipulating builds for debugging, running on CI servers, controlling
> > > > executions in child poms, etc. Even if it's not recommended to run
> > > > unattended, it's still possible, so a skip option is useful.
> > >
> > > Me too.  I don't see the point about arguing that some goal 'doesn't
> > > belong in a lifecycle'. We can't predict what people will find useful.
> >
> > Why not add the ability to skip various (named) activities to maven
> itself?
> >
>
> That exists. It's called profiles... but it's very verbose in the POM. It's
> much more pleasant to work with if the behavior of the individual plugin is
> flexible through configuration.
>

Editing a POM is way too heavy-handed IMO when I want to skip this and that
while I am experimenting with a build or debugging a build.

2c,
Gary

A feature could be added to Maven to skip specific named executions of

> plugins, I suppose... but that sounds like a feature that would require
> some discussion and debate before showing up in some future version of
> Maven. The proposal is something which could be done today, which would
> work, regardless of the version of Maven you're using, and which is
> consistent with similar configurable behavior in countless existing
> plugins.
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: opinions on MJAVADOC-451

[Chas Honton]

+1

Chas

> On Aug 5, 2016, at 7:37 AM, Christopher  wrote:
> 
> I'm always in favor of adding skip properties. They are very useful for
> manipulating builds for debugging, running on CI servers, controlling
> executions in child poms, etc. Even if it's not recommended to run
> unattended, it's still possible, so a skip option is useful.
> 
>> On Thu, Aug 4, 2016, 11:47 Richard Sand  wrote:
>> 
>> Anyone want to give this a quick read/opinion? :-)
>> 
>> -Richard
>> 
>> -- Original Message --
>> 
>> From: "Richard Sand" 
>> To: dev@maven.apache.org
>> Sent: 8/1/2016 6:33:30 PM
>> Subject: opinions on MJAVADOC-451
>> 
>>> Hi all,
>>> 
>>> I'd like to ask for opinions on
>>> https://issues.apache.org/jira/browse/MJAVADOC-451. Robert Scholte and
>>> I have been discussing this off list and essentially disagree on it.
>>> 
>>> The request is very simple - to add a "skip" parameter to the
>>> javadoc:fix goal. In my projects we are using the fix goal unattended,
>>> i.e. with the parameter "force=true", as part of the regular build
>>> lifecycle.
>>> 
>>> Most goals (including javadoc) that run in the regular lifecycle have a
>>> skip option. Robert's position (and forgive me if I misrepresent this
>>> at all Robert and please weigh in) is that javadoc:fix should not be
>>> used in the lifecycle and that the goal should in fact have
>>> requireDirectInvocation=true. He also pointed out to me that I can
>>> create a profile to enable/disable the goal as an alternative.
>>> 
>>> My opinion is that, since the goal does not require direct invocation,
>>> then running within the lifecycle has to be considered acceptable use
>>> of the goal. And having a skip parameter adds 5 lines of code, is a
>>> common and normal pattern used by many other plugins/goals, and allows
>>> the goal to be used in this fashion without introducing even more
>>> profiles.
>>> 
>>> I've submitted patches for this issue and also several other issues in
>>> the javadoc plugin as I continue to work through getting the goal to
>>> work well automated. Just pointing out that I'm not just asking for the
>>> larger community to do stuff to make my life easier - I'm trying to
>>> contribute as best I can and provide patches for what I uncover.
>>> 
>>> Best regards,
>>> 
>>> Richard
>>> 
>>> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: opinions on MJAVADOC-451

[Robert Scholte]

Hi all,

the request for the skip-parameter started as a requirement to break an  
infinite loop. When I discovered how the plugin was used and told that  
binding the plugin to a different phase, the loop was gone. Even though,  
the request for the skip parameter stayed.


I consider the javadoc:fix goal in the same range as the release:prepare  
release:perform combination (why as is everything executed twice) and  
cobertura-maven-plugin (why are the tests executed twice) and the fix-goal  
is probably even worse.
You really must understand what this goal does under the hood. It calls  
clirr:check, which always executes compile up front since it requires  
compiled classes. if you bind javadoc:fix to the compile goal, you'll get  
the infinite loop. Binding it to process-classes would fix this.
But from now on sources and classes are out of sync! This means that  
plugins like maven-xref-plugin gives you wrong information.
So to be perfect, after executing javadoc:fix, one should recompile the  
code.
But wait, now the sources in SCM are out of sync too. If you get an  
exception and try to fix this based on the linenumbers in scm, you're  
fooled. So it must be javadoc:fix + compiler:compile + scm:commit.
We can only force plugins to be executed up front, not afterwards (which  
is probably a good thing).

It is impossible to come to one truth right now.

For this reason I'd go for activating the requiresDirectInvocation flag,  
which means it cannot be used as part of the lifecycle anymore. (so yes,  
we have control over how goals can be used). However, this will make the  
plugin useless for persons like Richard.


So for me the impact  of adding skip to the javadoc:fix goal is way too  
big if it reflects uses as part of the lifecycle.

And as said: in this case the profile solution is fine.

regards,
Robert

ps. Adding the skip-parameter parameter to the AbstractMojo is not  
possible unless every plugin adds the skip logic to its own execute()  
method. Give it a try ;) We need to wait for Java8 runtime, where we can  
add a default method for it to the Mojo interface.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: opinions on MJAVADOC-451

[Christian Schulte]

Am 08/06/16 um 11:35 schrieb Robert Scholte:
> I consider the javadoc:fix goal in the same range as the release:prepare  
> release:perform combination (why as is everything executed twice) and  
> cobertura-maven-plugin (why are the tests executed twice) and the fix-goal  
> is probably even worse.

[...]

> For this reason I'd go for activating the requiresDirectInvocation flag,  
> which means it cannot be used as part of the lifecycle anymore. (so yes,  
> we have control over how goals can be used). However, this will make the  
> plugin useless for persons like Richard.

If a plugin is intended to be used only directly then flagging it that
way makes sense. Stops issues like this from popping up. If it couldn't
have been used in a lifecycle, I think no-one would have requested to
remove that flag.

BTW, the release:prepare release:perform goals do not carry that flag.
They also should following this reasoning. Maybe others as well.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: opinions on MJAVADOC-451

[Christian Schulte]

Am 06.08.2016 um 11:35 schrieb Robert Scholte:

fooled. So it must be javadoc:fix + compiler:compile + scm:commit.


The Maven-way would be a lifecycle for things like that, right? Like the 
clean or site lifecycle. A general purpose "manage source code" 
lifecycle with phases like "prepare-main-sources, manage-main-sources, 
prepare-test-sources,manage-test-sources,commit". Just an example. No 
forking involved.


Regards,
--
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: opinions on MJAVADOC-451

[Richard Sand]

Hi all -

the request for the skip-parameter started as a requirement to break an 
 infinite loop. When I discovered how the plugin was used and told that 
 binding the plugin to a different phase, the loop was gone. Even 
though,  the request for the skip parameter stayed.


Untrue. I opened MJAVADOC-451 first. It was the first time I'd submitted 
anything from the Maven community. I hadn't even found the looping 
behavior yet. The point was that the looping behavior was trivial to fix 
because I had *already* added the skip.



I consider the javadoc:fix goal in the same range as the 
release:prepare  release:perform combination (why as is everything 
executed twice) and  cobertura-maven-plugin (why are the tests executed 
twice) and the fix-goal  is probably even worse.
javadoc:fix with force=true is akin to running the checkstyle plugin but 
having it actually fixing the formatting in band. But - this behavior 
requires force=true. You accidentally stumble on this behavior.


So forget about force=true for a moment. What if I simply want to force 
ALL of my developers, because they are so lazy about entering proper 
javadocs, to have the fix goal executed interactively? But I want them 
to be able to explicitly skip it, or for the CI servers to skip it?


The point is, there are many ways that people can find to use the 
capabilities of a given plugin.


You really must understand what this goal does under the hood. It calls 
 clirr:check, which always executes compile up front since it requires  
compiled classes. if you bind javadoc:fix to the compile goal, you'll 
get  the infinite loop. Binding it to process-classes would fix this.
But from now on sources and classes are out of sync! This means that  
plugins like maven-xref-plugin gives you wrong information.
So to be perfect, after executing javadoc:fix, one should recompile the 
 code.
But wait, now the sources in SCM are out of sync too. If you get an  
exception and try to fix this based on the linenumbers in scm, you're  
fooled. So it must be javadoc:fix + compiler:compile + scm:commit.
We can only force plugins to be executed up front, not afterwards 
(which  is probably a good thing).

It is impossible to come to one truth right now.

For this reason I'd go for activating the requiresDirectInvocation 
flag,  which means it cannot be used as part of the lifecycle anymore. 
(so yes,  we have control over how goals can be used). However, this 
will make the  plugin useless for persons like Richard.
Here is one point I agree with you - *if* this goal must NEVER be 
allowed to run in the lifecycle, then the skip parameter makes no sense, 
and requiresDirectInvocation should be set to true.


But remember the goal already has the force=true option. Its not like 
people can accidentally introduce this without giving some thought to 
what they are doing.


So in the end I think you are simply taking away a potentially useful 
option. I totally understand the risks of having the local files 
changing and the line numbers not lining up to what is in SCM. But I've 
decided, the way my team operates, that I accept that risk, and I am 
otherwise getting a good value out of this plugin. So I would be 
disappointed if the plugin changed to requireDirectInvocation. We could 
add an additional INFO message when using the goal with force=true 
saying "Hey we're about to automatically scan through and potentially 
change your code!"


I think everyone on the list agrees that a skip parameter is good *if* 
the plugin remains as it is and can be executed as part of the 
lifecycle. So I'm  pushing for a decision here:


1) add the skip option (and potentially a stronger warning message on 
force=true as well)


or

2) set requireDirectInvocation to true


So for me the impact  of adding skip to the javadoc:fix goal is way too 
 big if it reflects uses as part of the lifecycle.

And as said: in this case the profile solution is fine.

regards,
Robert

ps. Adding the skip-parameter parameter to the AbstractMojo is not  
possible unless every plugin adds the skip logic to its own execute()  
method. Give it a try ;) We need to wait for Java8 runtime, where we 
can  add a default method for it to the Mojo interface.
Agreed, I was thinking the same thing about java8 and the Mojo 
interface. Maven 4.0?


Best regards,

Richard


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org