Hello Stephen, sounds like a good idea. This would help a lot, we have projects using custom gradle scripts to achieve things like this. Using name spacing seems to be a good idea here.
Regards Mirko -- Sent from my mobile Am 08.02.2016 23:33 schrieb "Stephen Connolly" < stephen.alan.conno...@gmail.com>: > So I was thinking somewhat about the issues with custom lifecycles. > > One of the nice things I like about Maven is that the use of the standard > lifecycles helps orientate new developers and prevents the sprawl of ANT > targets. > > When I look at all the other build systems, what I keep missing in them is > the standard lifecycle. Every time you land on a project you end up > spending altogether far too much time trying to figure out the special > incantations required to build the project... Is it `ant clean build`, is > it `ant distclean dist`, etc. And this is not just an ANT issue, it affects > all the build systems from make onwards. > > Now the thing is that Maven actually supports custom lifecycles, so I can > create a custom lifecycle with a custom list of phases using whatever names > I decide... The reason people don't do this is because it's seen as hard to > do... > > There is that quote: "Nothing is either good or bad, but thinking makes it > so" > > By being perceived as hard to do, custom lifecycles have resulted in a > solid set of well defined phases... > > On the other hand, people end up abusing the standard lifecycle in order to > do lifecycle like things... Has anyone seen people using special profiles > coupled with plugins bound to early lifecycle phases to do non-build > related things? I know I have been guilt of this... After all `initialize` > and `validate` are generally no-op phases and if you use `<defaultGoal>` in > the profile you can achieve quite a lot... Except now the old problem is > back... How do I start up a local test environment: `mvn -Pcreate-test-env > -pl :test-env`... Well that's non-obvious to discover... And it's not very > portable either... In fact give me 3 months away and I'll probably have > forgotten how to do it myself... > > So much nicer would be to actually start using custom lifecycles... > > First off, let's say we define a deployment lifecycle with goals to assist > shipping the artifacts to deployment environments. So you want to type `mvn > ship -Pproduction` to ship the artifacts to production. In a multi module > project this will only work if all modules in the project have the > extension with this custom lifecycle in scope... So good luck to you if you > have to pull in some projects to your reactor where you only have read > access to SCM and they don't use your extension... You used to end up > needing a custom distribution of Maven with the extension pre-loaded... > > This is somewhat easier with the .mvn directory... As we can ensure the > extension defining the custom lifecycle is loaded for all projects in the > repository... > > But here is my problem: > What happens when there are two extensions defining different > lifecycles with the same phase names? > > So I've added my extension which defines the `ship` phase and there's also > another project in the reactor with an extension which has defined a > different lifecycle which also has the phase `ship`... Who wins? > > Well the current answer to who wins is: "first in the reactor wins" > > So if I have the .mvn directory loading up the custom extension and the > other project is second in the reactor then my `ship` will win... But if > the other project is first in the reactor then that project's `ship` may > win... And then the build will fail as on the second reactor module that > lifecycle does not exist. > > So it seems obvious to me that we need to provide a way to namespace > lifecycle phases... So that > > `mvn default::deploy` and `mvn deploy` are logically the same as long as > only the "default" build lifecycle defines a "deploy" phase. The same would > work for `mvn clean::clean` vs `mvn clean` and `mvn site::site-deploy` vs > `mvn site-deploy` for the "clean" and "site" lifecycles respectively > > The second nice thing about namespacing lifecycles is that we can > automatically trim the project list based on those projects that define the > lifecycles... > > So then > > `mvn ship::ship` > > will only operate on those projects that actually have an extension that > defines the ship lifecycle... > > If we take this further we may also need to ack that we have no control > over the extensions that define lifecycles with specific IDs... So you may > need to further qualify the lifecycle... `mvn > groupId:artifactId:version::lifecycleId::phase` being the fully specified > phase > > What do people think? Is this something to consider? Will I file a JIRA > > > -- > Sent from my phone >
