Message-ID: <716286045.1347.1409188743159.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1346_1306012176.1409188743158" ------=_Part_1346_1306012176.1409188743158 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
We need the ability to bind a Mojo to a custom LifeCycle.=20
Our specific use case is to be able to perform extra tasks during releas= e that need to occur at times other than the small window provided by the m= aven-release-plugin's run-preparation-goals and run-perform-goals phases. I= n particular we need Mojos to execute during the scm-commit-development and= scm-commit-rollback phases.=20
So we need the ability to bind our plugin's Mojos to those phases.= =20
I would think that there are probably many other use cases, for other cu=
stom LifeCycles, not only for the release-plugin.
A mechanism for bin= ding Mojos to custom LifeCycles provides a much cleaner mechanism for plugi= ns like the release-plugin that are aware that they need to integrate with = other plugins.
I would like to propose a syntax similar to:=20 =20
where the groupId and artifact binding of the phase follow the same defa= ulting process at that used to define dependencies. That is the above bindi= ng could be rewritten as:=20 =20
or even=20 =20
The other (IMHO poorer) option would be to include the LifeCycle of the = release-plugin as part of the Maven core.=20
Without this proposal we will=20
I'd really like to use a base version of the release-plugin and I'd real= ly like to be able to provide the subclispe-tags-plugin to the community.= p>=20
NB this was originally raised as http://jira.code= haus.org/browse/MRELEASE-235