On Tuesday 9 February 2016, Robert Scholte <[email protected]> wrote:
> So this sounds like Maven will slowly shift from build management tool to > lifecycle management tool, which maybe isn't too bad. Well I think that is the "missing feature" that drives people elsewhere... > > Reading this I really wonder if it is worth investigating in this. I hope > this is so rare that if you hit this issue, you have control over at least > one of the lifecycles so that you can adjust it. > Namespaces are a solution, but I wonder if one would user them if they > exist. In batchmode you probably must. > Instead I would try to detect the conflict and give the user the choice > which of the lifecycles he wants to execute. This list should never become > as long as the available archetypes right now! > > And if there are lifecycles which makes sense, why not adopt them inside > Maven? I agree, if we see a good generally useful lifecycle, we should pick it up and define the phase names > > So my first action would be to throw an exception in case there's an > unresolvable phase name conflict. Perhaps if it's a maven bundled phase we just force using that one... But otherwise, yes we could blow up if there is a conflict... Though I like namespaces to auto-select the project module subset to run on > > my 2 cents, > Robert > > > Op Mon, 08 Feb 2016 23:33:54 +0100 schreef Stephen Connolly < > [email protected]>: > > 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 >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Sent from my phone
