I agree that we should document changes between Maven 3 and 4 thoroughly, a migration table is a good idea. I've added a comment in the maven-site ticket: https://issues.apache.org/jira/browse/MNGSITE-444 Feel free to add your scenarios there.
I'm convinced your scenarios can be done using Maven 4 in the same manner as Maven 3, but indeed, some existing builds might have to be tweaked (and I understand that buildserver setups will have to be changed). Op di 23 mrt. 2021 om 08:45 schreef Romain Manni-Bucau < [email protected]>: > > > Le mar. 23 mars 2021 à 08:34, Martin Kanters <[email protected]> a > écrit : > >> Alright, let's take a look back at your problem situation. I tried to >> explain others, but figured out I didn't completely understand it. >> Is this what you meant? >> >> root: >> ... foo: >> ........ foo-a >> ........ foo-b >> ... images: >> ........ image-a >> ........ image-b >> ........ subparent: >> ............. subimage-a >> ... assemblies: >> ........ assembly-a >> ........ assembly-b >> >> Non-flat cases are not broken in the new setup I believe: >> > mvn <goal> -pl !root, !foo, !foo-a, !foo-b, !images, !subparent, >> !assemblies -N >> This will build image-a, image-b, subimage-a, assembly-a, assembly-b >> > > Hmm, this is what mvn 3.6.3 without -N. > Here you excluded foo-{a,b} but case is really to just exclude undesired > parents (images/assemblies). > If I'm right that dropping foo, foo-a and foo-b from the build i break the > build (images/* depend on it) this does not work. > > Overall to be more concrete I see all the cases used: > > - dropping just one/multiple root(s) (including only very root one to skip > license checking for ex ;)) pom but keeping all the reactor except this > parent(s), > - dropping a few children/leaves > - building at the same time hierarchical submodules and just children of a > submodule > > If we can make a table with all these cases as of today (mvn 3) and > tomorrow (mvn 4) and migration is very smooth let's do it. > Once done we can evaluate the user value of this change more obviously > probably but for me it is clearly negative for a core dev target (thing we > shouldn't care IMHO since it impacts very few people vs a lot - don't > underestimate the cost to just add a -N in a ton of CI and breaking > platforms integrating us). > > > >> >> Is this what you meant? Please let me know exactly what modules you want >> to build in this project structure, or improve the project structure. >> >> Op ma 22 mrt. 2021 om 21:00 schreef Romain Manni-Bucau < >> [email protected]>: >> >>> >>> >>> Le lun. 22 mars 2021 à 20:49, Martin Kanters <[email protected]> >>> a écrit : >>> >>>> Alright, there indeed are specific problems that cannot be solved with >>>> -pl. Then again the automatic recursiveness does give benefit that we >>>> didn't have in 3.6.3. >>>> Your problem can be solved using profiles, multiple invocations, exact >>>> -pl module specifications or different directory formats. >>>> >>> >>> Profiles are almost never a solution since they break the build by not >>> being activated automatically - until we have alias but I fear this would >>> be a long dicussion for a core feature. >>> Exact -pl is not maintenable compared to current solution which works >>> fine. >>> Changing the project structure because we break the CLI would be a shame >>> IMHO. >>> >>> >>>> I guess there is no silver bullet, at least we did not find one. We >>>> have to continue at some point, though. Personally I've heard more people >>>> in favor of the -N solution than against. >>>> >>> >>> I would have been in this camp if it was not breaking any existing usage >>> but it does so we just introduced a bug we must fix for next release...does >>> not sound like something better. >>> >>> >>>> We can always improve later on, if we have found a better solution. >>>> >>> >>> Works for me while it is before next release (= we don't break any *end >>> user* without a proper solution compared to the working solution of today >>> and likely without any breaking change which would be the worst we can do >>> as a build tool - plugin level is another topic where it can be more >>> flexible). >>> >>> Side note: the -plN (or whatever name it gets) was not shocking and >>> solving all these issues more properly than a global toggle which can't >>> solve the backward compatibility point by construction. >>> >>> >>>> >>>> Op ma 22 mrt. 2021 om 17:51 schreef Romain Manni-Bucau < >>>> [email protected]>: >>>> >>>>> >>>>> >>>>> Le lun. 22 mars 2021 à 16:07, Martin Kanters <[email protected]> >>>>> a écrit : >>>>> >>>>>> Err, let's keep using examples to avoid miscommunication :p If I >>>>>> understand you correctly, you mean this: >>>>>> >>>>>> root: >>>>>> ... images: >>>>>> ........ image-a >>>>>> ........ image-b >>>>>> ... assemblies: >>>>>> ........ assembly-a >>>>>> ........ assembly-b >>>>>> >>>>>> When running from root, you can use: >>>>>> >>>>>> > mvn <goal> -pl !root,!images,!assemblies -N >>>>>> >>>>>> This will build image-a, image-b, assembly-a, assembly-b. It skips >>>>>> all three aggregators. >>>>>> >>>>> >>>>> Add root/foo/{a,b} module in the picture - or more a real case is >>>>> images/subparent/* and images/{all but subparent} - this is the broken >>>>> case. >>>>> basically in other words, it only works for flat cases (one level) but >>>>> not in all other cases - this is why -N is not a solution to the issue as >>>>> discussed in this thread. >>>>> >>>>>> >>>>>> By the way, -pl !xxx,yyy is still perfectly possible. >>>>>> >>>>>> Martin >>>>>> >>>>>> Op ma 22 mrt. 2021 om 15:47 schreef Romain Manni-Bucau < >>>>>> [email protected]>: >>>>>> >>>>>>> >>>>>>> >>>>>>> Le lun. 22 mars 2021 à 15:03, Martin Kanters < >>>>>>> [email protected]> a écrit : >>>>>>> >>>>>>>> Hey Romain, >>>>>>>> >>>>>>>> Your example will work with -N when MNG-7112 [1] is implemented >>>>>>>> (which we >>>>>>>> are working on as we speak). >>>>>>>> MNG-7112 says: -N together with a project exclusion (via -pl) will >>>>>>>> make the >>>>>>>> project exclusion non-recursive. So it will not exclude the >>>>>>>> children. >>>>>>>> Following your example, >>>>>>>> >>>>>>>> > cd images-parent && mvn myplugin:mygoal -pl '!images-parent' *-N* >>>>>>>> >>>>>>>> will work. It will only build the children of images-parent. -N >>>>>>>> will apply >>>>>>>> to -pl when -pl is present. >>>>>>>> >>>>>>>> That said, -N without -pl will work as it works in 3.6.3: only the >>>>>>>> pom in >>>>>>>> the current directory will be built (or the pom specified with -f). >>>>>>>> >>>>>>>> I hope this clears it up, >>>>>>>> >>>>>>> >>>>>>> Not really - but my example was maybe not perfect :s - it works only >>>>>>> in the case you enter images folder but typically, as almost mentionned >>>>>>> ;) >>>>>>> - this is often used for images + assemblies (2 submodule trees) and it >>>>>>> works today, if I add -N it will not work anymore and I can't do -pl >>>>>>> parent >>>>>>> -plN '!parent' so I'm still blocked or do you see a way to make current >>>>>>> behavior working as expected? Or do you mean if I use -pl -xxx I can't >>>>>>> use >>>>>>> -pl yyy anymore (both became exclusive which would be another blocker >>>>>>> for >>>>>>> me). >>>>>>> >>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>>> [1] https://issues.apache.org/jira/browse/MNG-7112 >>>>>>>> >>>>>>>> Op ma 22 mrt. 2021 om 13:26 schreef Romain Manni-Bucau < >>>>>>>> [email protected]>: >>>>>>>> >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > Just saw the PR was merged but it is actually still a regression, >>>>>>>> what's >>>>>>>> > the plan to keep this kind of build working: >>>>>>>> > >>>>>>>> > Structure: >>>>>>>> > >>>>>>>> > . root >>>>>>>> > |- core >>>>>>>> > |- ... >>>>>>>> > `- images-parent // can be assemblies too or anything else >>>>>>>> > |- image1 >>>>>>>> > |- ... >>>>>>>> > `- imageN >>>>>>>> > >>>>>>>> > > cd images-parent && mvn myplugin:mygoal -pl '!images-parent' >>>>>>>> > >>>>>>>> > This command has the big advantage to launch a command on all >>>>>>>> children but >>>>>>>> > the root pom (where the plugin would fail - note in practise it >>>>>>>> is a >>>>>>>> > combination of N plugins in general). >>>>>>>> > >>>>>>>> > You mentionned '-N' which does not solve this new bug AFAIK, a >>>>>>>> profile does >>>>>>>> > not as well, a skip property or any additional requirement on >>>>>>>> mojo are >>>>>>>> > indeed undersired, so what is the plan to get back to something >>>>>>>> functional? >>>>>>>> > >>>>>>>> > Romain Manni-Bucau >>>>>>>> > @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>> > <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>>> > <http://rmannibucau.wordpress.com> | Github < >>>>>>>> > https://github.com/rmannibucau> | >>>>>>>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>>> > < >>>>>>>> > >>>>>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>>>> > > >>>>>>>> > >>>>>>>> > >>>>>>>> > Le dim. 28 févr. 2021 à 11:57, Romain Manni-Bucau < >>>>>>>> [email protected]> >>>>>>>> > a >>>>>>>> > écrit : >>>>>>>> > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte < >>>>>>>> [email protected]> a >>>>>>>> > > écrit : >>>>>>>> > > >>>>>>>> > >> We should be talking about consistency. >>>>>>>> > >> We have a flag --non-recursive, which implies that recursive >>>>>>>> is the >>>>>>>> > >> default. >>>>>>>> > >> With Maven 3 that is just not always the case and this should >>>>>>>> be fixed. >>>>>>>> > >> Maven 4 is the right version to do so. >>>>>>>> > >> >>>>>>>> > >> Using -pl <arg> -N does not work with Maven 3: it'll say >>>>>>>> "Couldn't find >>>>>>>> > >> the selected project in the reactor" >>>>>>>> > >> Being able to use this combination AND making -pl recursive by >>>>>>>> default >>>>>>>> > >> makes everything consistent. >>>>>>>> > >> >>>>>>>> > > >>>>>>>> > > Can be seen this way so choice is between consistency and >>>>>>>> backward >>>>>>>> > > compatibility, I'm clearly favoring last one which would be way >>>>>>>> more >>>>>>>> > costly >>>>>>>> > > in the ecosystem than the first one as of today (plus it is not >>>>>>>> that >>>>>>>> > > inconsistent today since it either works or is forbidden). >>>>>>>> > > >>>>>>>> > > >>>>>>>> > >> >>>>>>>> > >> The argument that this change will break backwards >>>>>>>> compatibility is less >>>>>>>> > >> important to me and is actually not true. By switching to >>>>>>>> recursive by >>>>>>>> > >> default and calling -pl <module> it will still build the >>>>>>>> module ... and >>>>>>>> > >> more. We're not building less! >>>>>>>> > >> >>>>>>>> > > >>>>>>>> > > But we break a lot which is the worse a so much used project >>>>>>>> as Maven >>>>>>>> > can >>>>>>>> > > do for a new major. >>>>>>>> > > >>>>>>>> > > >>>>>>>> > >> >>>>>>>> > >> The question you need to ask yourself every time in case of a >>>>>>>> pom >>>>>>>> > >> packaged project: >>>>>>>> > >> Do I want to build the parent? call -pl <arg> -N >>>>>>>> > >> Do I want to build the aggregated modules call -pl <arg> >>>>>>>> > >> >>>>>>>> > >> Consistency is key: ensure that you can always add >>>>>>>> --non-recursive/-N. >>>>>>>> > >> This will always and only build the selected projects, no >>>>>>>> exclusions, >>>>>>>> > and >>>>>>>> > >> otherwise it'll be recursive. >>>>>>>> > >> >>>>>>>> > > >>>>>>>> > > pl definition is about built module so you enforce consistency >>>>>>>> changing >>>>>>>> > > the definition which is unfair and really the impact is not >>>>>>>> blocking >>>>>>>> > since >>>>>>>> > > the fix is not hard but really bothering for *no* new feature >>>>>>>> on user >>>>>>>> > land >>>>>>>> > > so I really prefer the alternatives. >>>>>>>> > > >>>>>>>> > > >>>>>>>> > >> >>>>>>>> > >> Robert >>>>>>>> > >> >>>>>>>> > >> On 26-2-2021 14:45:18, Romain Manni-Bucau < >>>>>>>> [email protected]> >>>>>>>> > wrote: >>>>>>>> > >> Le ven. 26 févr. 2021 à 14:30, Robert Scholte a >>>>>>>> > >> écrit : >>>>>>>> > >> >>>>>>>> > >> > This discussion is about aggregators, and not about parent. >>>>>>>> > >> > Quite often an aggregator is also the parent of its modules, >>>>>>>> but that >>>>>>>> > is >>>>>>>> > >> > not required. >>>>>>>> > >> > >>>>>>>> > >> >>>>>>>> > >> Ack >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> > >>>>>>>> > >> > Calling -pl with Maven3 behaves unnatural: if you want to >>>>>>>> > >> > call a specific aggregator, you want its modules to be built. >>>>>>>> > >> > >>>>>>>> > >> >>>>>>>> > >> I disagree, it looks unatural if you know it is an aggregator >>>>>>>> but there >>>>>>>> > is >>>>>>>> > >> no way to know form maven standpoint, it is a pom which >>>>>>>> children and >>>>>>>> > with >>>>>>>> > >> packaging=pom which does not mean it is an aggregator. >>>>>>>> > >> To give a quick example of that: the strict aggregator case >>>>>>>> will desire >>>>>>>> > to >>>>>>>> > >> build children but not the aggregator itself (functionally) >>>>>>>> whereas all >>>>>>>> > >> other cases want the pom itself. >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> > >>>>>>>> > >> > Hence I still support the change to make this the default >>>>>>>> behavior. >>>>>>>> > >> > >>>>>>>> > >> > In those rare cases where you want to build it only because >>>>>>>> it is a >>>>>>>> > >> parent >>>>>>>> > >> > (and not for the aggregator part), it makes sense to add >>>>>>>> > --non-recursive >>>>>>>> > >> > >>>>>>>> > >> >>>>>>>> > >> It is not rare, it is actually very very common to use it as a >>>>>>>> prestep >>>>>>>> > on >>>>>>>> > >> CI builds and the new behavior break it all. >>>>>>>> > >> Since the value of pl is already an expression >>>>>>>> ([groupId]:artifactId), >>>>>>>> > it >>>>>>>> > >> is saner to use it and enrich this semantic to support >>>>>>>> "project with >>>>>>>> > >> child" >>>>>>>> > >> meaning for end users IMHO. >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> > >>>>>>>> > >> > All the options you had in Maven 3 for selecting a subset of >>>>>>>> a >>>>>>>> > >> multimodule >>>>>>>> > >> > project are still available in Maven 4. >>>>>>>> > >> > >>>>>>>> > >> >>>>>>>> > >> Maven 4 is not an opportunity to break existing builds IMHO, >>>>>>>> it would >>>>>>>> > >> deserve maven, it is an opportunity to break internals and >>>>>>>> build >>>>>>>> > pipeline >>>>>>>> > >> for sure. >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> > >>>>>>>> > >> > To me the new behavior is much better. Maven 4 is the >>>>>>>> perfect version >>>>>>>> > to >>>>>>>> > >> > introduce these changes. >>>>>>>> > >> > >>>>>>>> > >> > thanks, >>>>>>>> > >> > Robert >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > On 26-2-2021 14:02:29, Romain Manni-Bucau wrote: >>>>>>>> > >> > I still think it is wrong to have such a global toggle + >>>>>>>> break >>>>>>>> > backward >>>>>>>> > >> > compatibility (-pl + -N is *already* used for what it is >>>>>>>> today which >>>>>>>> > is >>>>>>>> > >> not >>>>>>>> > >> > the proposal but -pl parent without -N is also already used >>>>>>>> and works >>>>>>>> > >> > well). >>>>>>>> > >> > You can also take into consideration that -pl -module -N >>>>>>>> meaning is >>>>>>>> > >> > completely broken with this new definition. >>>>>>>> > >> > For these 3 reasons I think we shouldn't break current API >>>>>>>> and either >>>>>>>> > >> add a >>>>>>>> > >> > new toggle/syntax (>parent or !!parent or whatever forbidden >>>>>>>> character >>>>>>>> > >> in >>>>>>>> > >> > module names/folder fits you) or not do anything since >>>>>>>> nothing >>>>>>>> > prevents >>>>>>>> > >> to >>>>>>>> > >> > build a subtree with -pl as of today, it is just a bit more >>>>>>>> verbose >>>>>>>> > >> than a >>>>>>>> > >> > single module selection. >>>>>>>> > >> > >>>>>>>> > >> > Romain Manni-Bucau >>>>>>>> > >> > @rmannibucau | Blog >>>>>>>> > >> > | Old Blog >>>>>>>> > >> > | Github | >>>>>>>> > >> > LinkedIn | Book >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > Le ven. 26 févr. 2021 à 13:16, Martin Kanters a >>>>>>>> > >> > écrit : >>>>>>>> > >> > >>>>>>>> > >> > > I've had a talk this morning with Robert Scholte and >>>>>>>> Maarten Mulders >>>>>>>> > >> > about >>>>>>>> > >> > > this, since I had the feeling we were not getting further >>>>>>>> in this >>>>>>>> > mail >>>>>>>> > >> > > thread. >>>>>>>> > >> > > >>>>>>>> > >> > > First of all, we all agreed that we definitely needed >>>>>>>> functionality >>>>>>>> > >> for >>>>>>>> > >> > > both recursive and non-recursive project selection. What >>>>>>>> Robert >>>>>>>> > >> prefers >>>>>>>> > >> > is >>>>>>>> > >> > > the following: reusing existing flags if possible and no >>>>>>>> extra magic >>>>>>>> > >> in >>>>>>>> > >> > the >>>>>>>> > >> > > -pl syntax. So that boils down to "-pl + -N". By default, >>>>>>>> project >>>>>>>> > >> > selection >>>>>>>> > >> > > will be recursive and by passing -N to it, it will be >>>>>>>> switched to >>>>>>>> > >> > > non-recursive. >>>>>>>> > >> > > >>>>>>>> > >> > > While first I was hesitant on this solution, I realize now >>>>>>>> that this >>>>>>>> > >> is >>>>>>>> > >> > the >>>>>>>> > >> > > most user-friendly solution. Technically -N might mean >>>>>>>> different >>>>>>>> > >> things >>>>>>>> > >> > > when used with and without -pl, but functionally it's the >>>>>>>> same. >>>>>>>> > >> > > >>>>>>>> > >> > > Two points of concern were: >>>>>>>> > >> > > - "it's a global switch, we cannot select a recursive and >>>>>>>> > >> non-recursive >>>>>>>> > >> > > project in one maven-command". That's true, but that's >>>>>>>> currently >>>>>>>> > also >>>>>>>> > >> not >>>>>>>> > >> > > possible in 3.6.3 (automatically) and we should find the >>>>>>>> balance >>>>>>>> > >> between >>>>>>>> > >> > > usability and ensuring every possible scenario is possible. >>>>>>>> > >> > > - "it might cause a performance degradation". This is not >>>>>>>> true when >>>>>>>> > >> the >>>>>>>> > >> > > current behavior of -N will only change when used together >>>>>>>> with -pl. >>>>>>>> > >> > > >>>>>>>> > >> > > We’ll continue work in this direction. Feel free to raise >>>>>>>> any new >>>>>>>> > >> > concerns >>>>>>>> > >> > > if they arise. >>>>>>>> > >> > > >>>>>>>> > >> > > Martin >>>>>>>> > >> > > >>>>>>>> > >> > > Op zo 21 feb. 2021 om 22:29 schreef Romain Manni-Bucau >>>>>>>> > >> > > [email protected]>: >>>>>>>> > >> > > >>>>>>>> > >> > > > Put some comments inline but agree another minilanguage >>>>>>>> solution >>>>>>>> > >> works. >>>>>>>> > >> > > > Maybe -pl !!parent? >>>>>>>> > >> > > > >>>>>>>> > >> > > > Le dim. 21 févr. 2021 à 22:08, Martin Kanters >>>>>>>> > >> > > a >>>>>>>> > >> > > > écrit : >>>>>>>> > >> > > > >>>>>>>> > >> > > > > Romain: 2 has overlap if I'm not mistaken, what if the >>>>>>>> user >>>>>>>> > >> invokes: >>>>>>>> > >> > > mvn >>>>>>>> > >> > > > > -pl project-a -plr !project-a. Perhaps the user should >>>>>>>> be able >>>>>>>> > to >>>>>>>> > >> > only >>>>>>>> > >> > > > > select aggregator poms via -plr.. >>>>>>>> > >> > > > > And I'm not sure how the alias function would work. I >>>>>>>> assume >>>>>>>> > >> > something >>>>>>>> > >> > > > > like: >>>>>>>> > >> > > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > > Yes but same as today with -pl foo -pl!foo. We can fail >>>>>>>> in such a >>>>>>>> > >> case >>>>>>>> > >> > > too >>>>>>>> > >> > > > (my preference). Then more specific wins, ie -plr parent >>>>>>>> -pl >>>>>>>> > >> > !parent/foo >>>>>>>> > >> > > is >>>>>>>> > >> > > > obvious. >>>>>>>> > >> > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > > - pom.xml config (psuedo code): -pl parent, submodule-a, >>>>>>>> > >> > > > > submodule-b, submodule-c >>>>>>>> > >> > > > > - invocation mvn alias:rec. >>>>>>>> > >> > > > > If that assumption is correct, the user would have to >>>>>>>> manually >>>>>>>> > >> > maintain >>>>>>>> > >> > > > the >>>>>>>> > >> > > > > list of modules of "parent", while Maven can do this >>>>>>>> perfectly. >>>>>>>> > >> > > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > > Right, is it an issue? I dont think. Opposite is true >>>>>>>> too, you >>>>>>>> > need >>>>>>>> > >> to >>>>>>>> > >> > > > maintain children exclusions in general (all but "build" >>>>>>>> child >>>>>>>> > >> module >>>>>>>> > >> > or >>>>>>>> > >> > > > all but front or all but doc etc) so 1-1 IMHO. >>>>>>>> > >> > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > > > Falko: I don't intend to drop the recursive behavior >>>>>>>> either :) >>>>>>>> > >> > > > > I don't dislike the idea of adding a suffix to a >>>>>>>> project to >>>>>>>> > >> include >>>>>>>> > >> > > > > everything recursively and + might fix the shell >>>>>>>> expansion issue >>>>>>>> > >> > > (which * >>>>>>>> > >> > > > > has). >>>>>>>> > >> > > > > I guess this might be a nice alternative as well, but >>>>>>>> I'm not >>>>>>>> > >> sure if >>>>>>>> > >> > > > > everybody likes increasing the complexity of the -pl >>>>>>>> syntax. >>>>>>>> > "-pl >>>>>>>> > >> > > > !?proj/+" >>>>>>>> > >> > > > > or "-pl !?group:artifact+" is starting to look a bit >>>>>>>> like >>>>>>>> > magic.. >>>>>>>> > >> :) >>>>>>>> > >> > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > > > Martin >>>>>>>> > >> > > > > >>>>>>>> > >> > > > > Op zo 21 feb. 2021 om 21:38 schreef Falko Modler : >>>>>>>> > >> > > > > >>>>>>>> > >> > > > > > My 2 cents: Please don't drop the recursive behavior >>>>>>>> again >>>>>>>> > >> because >>>>>>>> > >> > it >>>>>>>> > >> > > > is >>>>>>>> > >> > > > > > really useful! >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > Crazy idea (just brainstorming here): >>>>>>>> > >> > > > > > -pl foo builds only foo >>>>>>>> > >> > > > > > -pl foo+ builds foo and its children, wherever they >>>>>>>> are >>>>>>>> > exactly >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > This would also co-exist with the ! and ? prefixes. >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > PS: Since if often use shell path completion, -pl >>>>>>>> foo/+ should >>>>>>>> > >> have >>>>>>>> > >> > > the >>>>>>>> > >> > > > > > same effect, ideally. >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > Cheers, >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > Falko >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > Am 21.02.2021 um 21:09 schrieb Romain Manni-Bucau: >>>>>>>> > >> > > > > > > Le dim. 21 févr. 2021 à 20:39, Martin Kanters >>>>>>>> > >> > > > > [email protected]> >>>>>>>> > >> > > > > > a >>>>>>>> > >> > > > > > > écrit : >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> Hm, so I guess that's indeed a valid reason to >>>>>>>> keep the old >>>>>>>> > >> > > > > > functionality >>>>>>>> > >> > > > > > >> working. Thanks for the enlightenment, Romain. >>>>>>>> > >> > > > > > >> Still I think it makes more sense to make project >>>>>>>> selection >>>>>>>> > >> > > > recursive >>>>>>>> > >> > > > > by >>>>>>>> > >> > > > > > >> default, but it's not straightforward to come up >>>>>>>> with a >>>>>>>> > nice >>>>>>>> > >> > > > > > combination of >>>>>>>> > >> > > > > > >> flags. >>>>>>>> > >> > > > > > >> Let's summarize: >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > >> 1. -pl + -N: >>>>>>>> > >> > > > > > >> While it does sound like the flag to re-use, I do >>>>>>>> not like >>>>>>>> > >> the >>>>>>>> > >> > > fact >>>>>>>> > >> > > > > > that -N >>>>>>>> > >> > > > > > >> works differently than normal when used together >>>>>>>> with -pl. >>>>>>>> > >> The >>>>>>>> > >> > > code >>>>>>>> > >> > > > > > would >>>>>>>> > >> > > > > > >> become more complex and the flag hard to explain >>>>>>>> to users. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > Does not really solves the issue as soon as you >>>>>>>> use it for 2 >>>>>>>> > >> > > > different >>>>>>>> > >> > > > > > kind >>>>>>>> > >> > > > > > > of modules until it becomes -plN which is 4 IMHO >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> 2. -pl + -plr: >>>>>>>> > >> > > > > > >> This gives the most flexibility, giving users the >>>>>>>> option to >>>>>>>> > >> > select >>>>>>>> > >> > > > > > >> non-recursive and recursive projects in one >>>>>>>> command. The >>>>>>>> > two >>>>>>>> > >> > flags >>>>>>>> > >> > > > > have >>>>>>>> > >> > > > > > a >>>>>>>> > >> > > > > > >> lot of overlap though, what happens when a >>>>>>>> project is >>>>>>>> > >> selected >>>>>>>> > >> > > with >>>>>>>> > >> > > > > -pl >>>>>>>> > >> > > > > > and >>>>>>>> > >> > > > > > >> deselected with -plr, which gets precedence etc. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > -plr without -pl, dont use a global toggle >>>>>>>> probably. >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > Ex: -pl parent-with-plugins -plr myaggregator -pl >>>>>>>> foo/bar >>>>>>>> > -plr >>>>>>>> > >> > > > > > docker-images >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> 3. -pl /* >>>>>>>> > >> > > > > > >> This gives the same flexibility as 2, but then in >>>>>>>> one >>>>>>>> > >> command. I >>>>>>>> > >> > > do >>>>>>>> > >> > > > > like >>>>>>>> > >> > > > > > >> that, but it can get messy with shell expansion. >>>>>>>> One other >>>>>>>> > >> thing >>>>>>>> > >> > > is >>>>>>>> > >> > > > > that >>>>>>>> > >> > > > > > >> with -pl you can select projects using the >>>>>>>> directory, but >>>>>>>> > >> also >>>>>>>> > >> > by >>>>>>>> > >> > > > > > >> (optionally groupid and) artifactId. The star (or >>>>>>>> its >>>>>>>> > >> > replacement) >>>>>>>> > >> > > > > could >>>>>>>> > >> > > > > > >> mean different things when used in either >>>>>>>> variant. Mind >>>>>>>> > that >>>>>>>> > >> > > > > submodules >>>>>>>> > >> > > > > > do >>>>>>>> > >> > > > > > >> not have to be placed directly in a subdirectory. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > Other issue is maven works with not linear (tree) >>>>>>>> children >>>>>>>> > so >>>>>>>> > >> can >>>>>>>> > >> > > be >>>>>>>> > >> > > > > > > complex to handle when parents or children are in >>>>>>>> other >>>>>>>> > >> physical >>>>>>>> > >> > > tree >>>>>>>> > >> > > > > or >>>>>>>> > >> > > > > > > even projects. >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> 4. (new idea) -pl + --pl-non-recursive: >>>>>>>> > >> > > > > > >> This does not have the flexibility 2 and 3 >>>>>>>> provides and we >>>>>>>> > >> would >>>>>>>> > >> > > > have >>>>>>>> > >> > > > > to >>>>>>>> > >> > > > > > >> introduce a new CLI flag. But it does have a very >>>>>>>> clear >>>>>>>> > goal >>>>>>>> > >> > which >>>>>>>> > >> > > > is >>>>>>>> > >> > > > > > easy >>>>>>>> > >> > > > > > >> to implement + explain. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > Hmm another global toggle? It will have the same >>>>>>>> combination >>>>>>>> > >> > issue >>>>>>>> > >> > > > than >>>>>>>> > >> > > > > > -N >>>>>>>> > >> > > > > > > IMHO. >>>>>>>> > >> > > > > > > So overall this sounds like reversing -pl and >>>>>>>> adding this >>>>>>>> > >> > > > complementary >>>>>>>> > >> > > > > > > option so 2 sounds the saner equivalent option for >>>>>>>> backward >>>>>>>> > >> > compat. >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> 5. Revert all and restore 3.6.3 functionality. >>>>>>>> > >> > > > > > >> Users could build extensions or plugin >>>>>>>> functionality to >>>>>>>> > >> achieve >>>>>>>> > >> > > the >>>>>>>> > >> > > > > > >> recursiveness. Not my favorite, because I think >>>>>>>> this is >>>>>>>> > >> > something >>>>>>>> > >> > > > > Maven >>>>>>>> > >> > > > > > >> Core should be able to provide out of the box. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > "Extension" can be built in too, just mentionned >>>>>>>> we can >>>>>>>> > solve >>>>>>>> > >> it >>>>>>>> > >> > > > > > > differently than enriching again the cli since >>>>>>>> functionally >>>>>>>> > we >>>>>>>> > >> > > > already >>>>>>>> > >> > > > > > > cover it. >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> 6. Make recursiveness the default and do not >>>>>>>> provide a >>>>>>>> > >> > workaround >>>>>>>> > >> > > > for >>>>>>>> > >> > > > > > >> non-recursiveness >>>>>>>> > >> > > > > > >> Since we are going to a new major version it's >>>>>>>> acceptable >>>>>>>> > to >>>>>>>> > >> > > > > > break/change >>>>>>>> > >> > > > > > >> existing behavior. We could wait until users >>>>>>>> complain and >>>>>>>> > >> then >>>>>>>> > >> > > build >>>>>>>> > >> > > > > > >> something in. >>>>>>>> > >> > > > > > >> Not my favorite (anymore) either, since >>>>>>>> apparently it's a >>>>>>>> > >> common >>>>>>>> > >> > > > > > use-case >>>>>>>> > >> > > > > > >> that we would break. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > Just my 2cts but sounds the worse. >>>>>>>> > >> > > > > > > Even if going major backward compat is key for not >>>>>>>> internals >>>>>>>> > >> > > > otherwise >>>>>>>> > >> > > > > we >>>>>>>> > >> > > > > > > do another build tool and break everyone which is >>>>>>>> always a >>>>>>>> > >> moment >>>>>>>> > >> > > of >>>>>>>> > >> > > > > > > temptation to reject the tool, in particular when >>>>>>>> trivial to >>>>>>>> > >> > avoid >>>>>>>> > >> > > > from >>>>>>>> > >> > > > > > > user PoV. >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> I understand the thread might've become hard to >>>>>>>> follow, so >>>>>>>> > I >>>>>>>> > >> > hope >>>>>>>> > >> > > > this >>>>>>>> > >> > > > > > >> summary helps other people to join the discussion. >>>>>>>> > >> > > > > > >> My current favorite is 4. >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > Personally, I'd say investigate alias option and >>>>>>>> if not >>>>>>>> > >> > satistying >>>>>>>> > >> > > > then >>>>>>>> > >> > > > > > use >>>>>>>> > >> > > > > > > 2. >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > > >>>>>>>> > >> > > > > > >> Martin >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > >> Op za 20 feb. 2021 om 17:53 schreef Romain >>>>>>>> Manni-Bucau >>>>>>>> > >> > > > > > >> [email protected]>: >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > >>> I like the regex idea but wildcard (*) does not >>>>>>>> work well >>>>>>>> > >> due >>>>>>>> > >> > to >>>>>>>> > >> > > > > common >>>>>>>> > >> > > > > > >>> shell expansion (or it already works but it is >>>>>>>> outside of >>>>>>>> > >> maven >>>>>>>> > >> > > > scope >>>>>>>> > >> > > > > > to >>>>>>>> > >> > > > > > >> be >>>>>>>> > >> > > > > > >>> concrete). >>>>>>>> > >> > > > > > >>> >>>>>>>> > >> > > > > > >>> My 2cts would be that, to be honest, I think we >>>>>>>> all lead >>>>>>>> > to >>>>>>>> > >> > have >>>>>>>> > >> > > > > > aliases >>>>>>>> > >> > > > > > >> in >>>>>>>> > >> > > > > > >>> maven for potentially very long commands (there >>>>>>>> was some >>>>>>>> > >> > threads >>>>>>>> > >> > > > > about >>>>>>>> > >> > > > > > >> it), >>>>>>>> > >> > > > > > >>> CLI then just needs to enable to >>>>>>>> activate/deactivate >>>>>>>> > things, >>>>>>>> > >> > not >>>>>>>> > >> > > to >>>>>>>> > >> > > > > be >>>>>>>> > >> > > > > > >>> clever and it would enable all combination >>>>>>>> without any >>>>>>>> > >> behavior >>>>>>>> > >> > > > > change >>>>>>>> > >> > > > > > >> nor >>>>>>>> > >> > > > > > >>> new option IMHO. Concretely "mvn alias:bd" would >>>>>>>> run "mvn >>>>>>>> > >> -pl >>>>>>>> > >> > > > foo/bar >>>>>>>> > >> > > > > > -pl >>>>>>>> > >> > > > > > >>> foo/dummy" for example. Thinking out loud it can >>>>>>>> be done >>>>>>>> > >> with a >>>>>>>> > >> > > > > plugin >>>>>>>> > >> > > > > > >>> already so can maybe give a try if it sounds >>>>>>>> like a good >>>>>>>> > >> idea >>>>>>>> > >> > for >>>>>>>> > >> > > > > > others >>>>>>>> > >> > > > > > >>> too. >>>>>>>> > >> > > > > > >>> >>>>>>>> > >> > > > > > >>> Romain Manni-Bucau >>>>>>>> > >> > > > > > >>> @rmannibucau | Blog >>>>>>>> > >> > > > > > >>> | Old Blog >>>>>>>> > >> > > > > > >>> | Github >>>>>>>> > >> > > > > > >>> https://github.com/rmannibucau> | >>>>>>>> > >> > > > > > >>> LinkedIn | Book >>>>>>>> > >> > > > > > >>> >>>>>>>> > >> > > > > > >>> >>>>>>>> > >> > > > > > >> >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > >>>>>>>> > >> > >>>>>>>> > >> >>>>>>>> > >>>>>>>> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>>>> > >> > > > > > >>> >>>>>>>> > >> > > > > > >>> Le sam. 20 févr. 2021 à 14:40, Falko Modler a >>>>>>>> > >> > > > > > écrit : >>>>>>>> > >> > > > > > >>> >>>>>>>> > >> > > > > > >>>> Thanks for the quick reaction/answers! >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > > >>>> TBH, I haven't fully understood why -N cannot >>>>>>>> be used >>>>>>>> > >> here. I >>>>>>>> > >> > do >>>>>>>> > >> > > > > > >>>> understand that -N reduces the reactor to one >>>>>>>> project >>>>>>>> > >> (before >>>>>>>> > >> > > > > project >>>>>>>> > >> > > > > > >>>> selection via -pl can kick in). >>>>>>>> > >> > > > > > >>>> But what if -N wouldn't be applied if -pl is >>>>>>>> present? It >>>>>>>> > >> would >>>>>>>> > >> > > > then >>>>>>>> > >> > > > > > >>> become >>>>>>>> > >> > > > > > >>>> a "secondary" option, only applying to the >>>>>>>> projects >>>>>>>> > >> selected >>>>>>>> > >> > or >>>>>>>> > >> > > > > > >>> deselected >>>>>>>> > >> > > > > > >>>> via -pl. >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > > >>>> However, the most flexible and fully backwards >>>>>>>> compatiple >>>>>>>> > >> > > solution >>>>>>>> > >> > > > > > >> would >>>>>>>> > >> > > > > > >>>> indeed be something like -plr as suggested >>>>>>>> before. You >>>>>>>> > >> could >>>>>>>> > >> > > then >>>>>>>> > >> > > > > also >>>>>>>> > >> > > > > > >>> mix >>>>>>>> > >> > > > > > >>>> and match -pl and -plr. >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > > >>>> Btw, half offtopic: I proposed [1] to add ? to >>>>>>>> -pl and in >>>>>>>> > >> that >>>>>>>> > >> > > > > context >>>>>>>> > >> > > > > > >> I >>>>>>>> > >> > > > > > >>>> also thought about wildcard support for -pl, >>>>>>>> but Robert >>>>>>>> > >> didn't >>>>>>>> > >> > > > like >>>>>>>> > >> > > > > > the >>>>>>>> > >> > > > > > >>>> idea. >>>>>>>> > >> > > > > > >>>> I'm just thinking whether -pl foo/* might be >>>>>>>> something >>>>>>>> > that >>>>>>>> > >> > > could >>>>>>>> > >> > > > > help >>>>>>>> > >> > > > > > >>>> here as well, but it wouldn't be trivial to do, >>>>>>>> I >>>>>>>> > suppose. >>>>>>>> > >> > > > > > >>>> PS: -help doesn't mention ! at all. >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > > >>>> [1] >>>>>>>> https://issues.apache.org/jira/browse/MNG-6511 >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > > >>>> Cheers, >>>>>>>> > >> > > > > > >>>> Falko >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > > >>>> >>>>>>>> > >> > > > > >>>>>>>> > >> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> > >> > > > > > >>>> 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] >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > > >>>>>>>> > >> > > > > >>>>>>>> > >> > > > >>>>>>>> > >> > > >>>>>>>> > >> > >>>>>>>> > >> >>>>>>>> > > >>>>>>>> > >>>>>>>> >>>>>>>
