You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Richard Sand <rs...@idfconnect.com> on 2016/08/01 22:33:30 UTC
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
Posted by Richard Sand <rs...@idfconnect.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Christian Schulte <cs...@schulte.it>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Christian Schulte <cs...@schulte.it>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Robert Scholte <rf...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Chas Honton <ch...@honton.org>.
+1
Chas
> On Aug 5, 2016, at 7:37 AM, Christopher <ct...@apache.org> 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 <rs...@idfconnect.com> wrote:
>>
>> Anyone want to give this a quick read/opinion? :-)
>>
>> -Richard
>>
>> ------ Original Message ------
>>
>> From: "Richard Sand" <rs...@idfconnect.com>
>> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Richard Sand <rs...@idfconnect.com>.
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 <ct...@apache.org> wrote:
>
>> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory <ga...@gmail.com> wrote:
>>
>>> On Aug 5, 2016 7:41 AM, "Benson Margulies" <bi...@gmail.com> wrote:
>>>
>>> On Fri, Aug 5, 2016 at 10:37 AM, Christopher <ct...@apache.org>
>> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Aug 5, 2016 at 3:51 PM, Christopher <ct...@apache.org> wrote:
> On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory <ga...@gmail.com>
> wrote:
>
> > On Aug 5, 2016 7:41 AM, "Benson Margulies" <bi...@gmail.com>
> wrote:
> > >
> > > On Fri, Aug 5, 2016 at 10:37 AM, Christopher <ct...@apache.org>
> > 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: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: opinions on MJAVADOC-451
Posted by Christopher <ct...@apache.org>.
On Fri, Aug 5, 2016 at 11:19 AM Gary Gregory <ga...@gmail.com> wrote:
> On Aug 5, 2016 7:41 AM, "Benson Margulies" <bi...@gmail.com> wrote:
> >
> > On Fri, Aug 5, 2016 at 10:37 AM, Christopher <ct...@apache.org>
> 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
Posted by Gary Gregory <ga...@gmail.com>.
On Aug 5, 2016 7:41 AM, "Benson Margulies" <bi...@gmail.com> wrote:
>
> On Fri, Aug 5, 2016 at 10:37 AM, Christopher <ct...@apache.org> 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 <rs...@idfconnect.com> wrote:
> >
> >> Anyone want to give this a quick read/opinion? :-)
> >>
> >> -Richard
> >>
> >> ------ Original Message ------
> >>
> >> From: "Richard Sand" <rs...@idfconnect.com>
> >> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: opinions on MJAVADOC-451
Posted by Benson Margulies <bi...@gmail.com>.
On Fri, Aug 5, 2016 at 10:37 AM, Christopher <ct...@apache.org> 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 <rs...@idfconnect.com> wrote:
>
>> Anyone want to give this a quick read/opinion? :-)
>>
>> -Richard
>>
>> ------ Original Message ------
>>
>> From: "Richard Sand" <rs...@idfconnect.com>
>> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: opinions on MJAVADOC-451
Posted by Christopher <ct...@apache.org>.
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 <rs...@idfconnect.com> wrote:
> Anyone want to give this a quick read/opinion? :-)
>
> -Richard
>
> ------ Original Message ------
>
> From: "Richard Sand" <rs...@idfconnect.com>
> 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
Posted by Richard Sand <rs...@idfconnect.com>.
Anyone want to give this a quick read/opinion? :-)
-Richard
------ Original Message ------
From: "Richard Sand" <rs...@idfconnect.com>
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
>
>