Hi, for information I once asked about a related topic on the mailing list but I think I didn't follow through. As a user, it felt natural to want to execute arbitrary goals at some point in the lifecycle and then want to continue with the lifecycle.
My use case was: $ mvn package javadoc:aggregate-jar install So I didn't consider this as garbage (as opposed to specify earlier phases after like $ mvn package compile) I saw two behaviors that I considered problematic: - it printed a weird counter [4/3] up until [7/3] (I have only 3 modules in the reactor) - it didn't continue but instead restarted the lifecycle (see end of message for full trace) NOTE1: It doesn't print the weird counter if you don't "restart" the lifecycle after executing the goal. Similarly, no weird counter if you use a non aggregating goal (although here it does restart the lifecycle). NOTE2: A separate issue is that the forked lifecycle also restarts the lifecycle (so 3 executions in total). But running with a non forking (but still aggregating) plugin (just searched for a random one) still shows the problem (2 executions) $ mvn clean package org.apache.maven.plugins:maven-remote-resources-plugin:3.3.0:aggregate install the full execution is something like this: $ mvn -version Apache Maven 3.9.16 (2bdd9fddda4b155ebf8000e807eb73fd829a51d5) $ mvn clean package javadoc:aggregate-jar install [INFO] ------------------------------ [INFO] ----------< first >----------- [INFO] Building first [1/3] goal of clean goals until package [INFO] --------------< second >----- [INFO] Building second [2/3] goal of clean goals until package [INFO] --------------< third >------ [INFO] Building third [3/3] goal of clean goals until package [INFO] ----------< first >---------- [INFO] Building first [4/3] >>> javadoc:3.12.0:aggregate-jar (default-cli) > compile @ first >>> [INFO] Forking first goals until compile [INFO] Forking second goals until compile [INFO] Forking third goals until compile <<< javadoc:3.12.0:aggregate-jar (default-cli) < compile @ first <<< --- javadoc:3.12.0:aggregate-jar (default-cli) @ first --- [INFO] ----------< first >---------- [INFO] Building first [5/3] goals until install (including ones from package) [INFO] --------------< second >----- [INFO] Building second [6/3] goals until install (including ones from package) [INFO] --------------< third >--------------- [INFO] Building third [7/3] goals until install (including ones from package) Cheers, Jon On Sun, Oct 4, 2026 at 5:13 PM Matthias Bünger <[email protected]> wrote: > > Hi Sebastian, > > first: Not sure if we should discuss the issue here or in the Github > issue :D > > My personal thought on the descirbed problem: I guess that in most cases > the user does not know that it's not needed to list all or that the user > does not know how to solve a specific situation, e.g. the user wants to > make sure that all projects are based, before installed/deployed so he > first runs "verify" on all and then "install/deploy" on all instead of > switching configuration "installAtEnd" / "deployAtEnd" to "true". Based > on the issue you linked there might be other cases that several > executes in a specific order might be a reasonible thing. > > So my gut feeling is: > > If two (or more) phases (including pre/post or new before/after) of the > same life cycle are listed in the "ascending" order without nothing else > (e.g. a specific plugin goal) in between, only the latest should be > executed and an INFO message tells the user about this. There should > also be a configuration option to disable this behavior and get back to > current state > > Phases of different lifecycles or phased of the same not in "ascending" > order should not be touched. For the later situation you could think > about an INFO message to "ask" if they really want to do this but not sure. > > Have a nice Sunday evening > > Matthias > > > > Am 02.10.2026 um 10:58 schrieb Sebastian Tiemann via dev: > > hey all, > > > > I had a look at this oldie https://issues.apache.org/jira/browse/MNG-5885 > > and that made me think about how to better handle maven executions like > > 'mvn package compile'. > > > > I would love to hear you thoughts about it. Here are some ideas: > > * Execute everything with all duplicate lifecycle phases and to > > nothing (current state) > > * Execute everything with all duplicate lifecycle phases and print a > > log message, e.g. warn > > * Filter the duplicate lifecycle phases and only execute the lifecycle > > phases from install in this case. Print a log message, e.g. warn > > o the filtering code could look like this: > > https://github.com/apache/maven/pull/13270 > > o hint: this also includes removing lifecycles from duplicated > > goals in a specific order > > * Throw an error: Doing this is a bad idea. > > > > Thanks, > > Sebastian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
