+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