Re: releasing plugin-tools 3.1

2012-06-26 Thread Olivier Lamy
Just applied. Thanks ! -- Olivier 2012/6/26 Tony Chemit che...@codelutin.com: On Mon, 25 Jun 2012 23:36:51 +0200 Robert Scholte rfscho...@apache.org wrote: Hi, I've discovered the cause of the HelpMojo plugin, Olivier has fixed it (thanks!). I have verified all the issues I've mentioned

How to extend the release phases of the DefaultReleaseManager?

2012-06-26 Thread Bernd.Vogt
Hi, is there a way to extend the release phases of the DefaultReleaseManager? I'd like to add a custom release phase to the list of the release managers prepare phases. The implementation of the custom phase should update some project specific files during the release preparation. Kind

Re: How to extend the release phases of the DefaultReleaseManager?

2012-06-26 Thread Stephen Connolly
95% of use cases that I have seen can be reached by using preparationGoals to invoke an additional plugin or mix in an additional profile 99.9% of use cases that I have seen can be reached by using preparationGoals and completionGoals to tidy up afterwards. Of the remaining 0.1% of use cases

AW: How to extend the release phases of the DefaultReleaseManager?

2012-06-26 Thread Bernd.Vogt
Actually, I'm not sure... I have a very special use case, let me try to explain it: * We implemented a maven core extension (see ${maven.home}/lib/ext/), called b2. * b2 is able to generate pom.xml files from plain eclipse plugin projects with all the necessary configuration to build it with

Re: How to extend the release phases of the DefaultReleaseManager?

2012-06-26 Thread Stephen Connolly
Ahh, yes... I remember now, I had some theoretical use cases for a transformationGoals (or prePreparationGoals) but no concrete use cases... until now. I think you just about have a valid use case for extending the lifecycle to have an optional set of goals which runs between updating the pom

Re: How to extend the release phases of the DefaultReleaseManager?

2012-06-26 Thread Stephen Connolly
of course you could just do mvn b2:prep-release release:prepare release:perform and have your plugin do the dancing games... but IIRC the pom checks take place on the loaded MavenProject and not on the on-disk pom On 26 June 2012 10:58, Stephen Connolly stephen.alan.conno...@gmail.com wrote:

Shade plugin non backward compatible change

2012-06-26 Thread Olivier Lamy
Hi, I don't know if you have a look @ MSHADE-112 Basically the goal is to be able to pass more and more parameters to the Shader. This need to change -void shade( SetFile jars, File uberJar, ListFilter filters, ListRelocator relocators, -ListResourceTransformer

Re: Shade plugin non backward compatible change

2012-06-26 Thread Benson Margulies
Here's my proposed plan. 1) I do something about MSHADE-123: move the default back to basedir. 2) I release 1.7.1. 3) You move the next version to 2.0 or 3.0, and fix MSHADE-112. 4) I apply the patch to MSHADE-103 that requires us to depend on Maven 3. 5) anyone who really wants a fix for