+1

Chas

> On Aug 5, 2016, at 7:37 AM, Christopher <ctubb...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to