Maven 4: -pl !... is not recursive

[Falko Modler <f....@gmx.net>]

Hi everyone,

I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
realized that -pl X will now also build submodules of X but -pl !X will
only exclude X, not its submodules.

Isn't this a bit inconsistent?

Cheers,

Falko


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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 <
rmannibucau@gmail.com>:

>
>
> Le mar. 23 mars 2021 à 08:34, Martin Kanters <ma...@apache.org> 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 <
>> rmannibucau@gmail.com>:
>>
>>>
>>>
>>> Le lun. 22 mars 2021 à 20:49, Martin Kanters <ma...@apache.org>
>>> 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 <
>>>> rmannibucau@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> Le lun. 22 mars 2021 à 16:07, Martin Kanters <ma...@apache.org>
>>>>> 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 <
>>>>>> rmannibucau@gmail.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le lun. 22 mars 2021 à 15:03, Martin Kanters <
>>>>>>> martinkanters@apache.org> 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 <
>>>>>>>> rmannibucau@gmail.com>:
>>>>>>>>
>>>>>>>> > 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 <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>> > a
>>>>>>>> > écrit :
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <
>>>>>>>> rfscholte@apache.org> 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 <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>> > 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
>>>>>>>> > >> > > rmannibucau@gmail.com>:
>>>>>>>> > >> > >
>>>>>>>> > >> > > > 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
>>>>>>>> > >> > > > > martinkanters@apache.org>
>>>>>>>> > >> > > > > > 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
>>>>>>>> > >> > > > > > >> rmannibucau@gmail.com>:
>>>>>>>> > >> > > > > > >>
>>>>>>>> > >> > > > > > >>> 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:
>>>>>>>> dev-unsubscribe@maven.apache.org
>>>>>>>> > >> > > > > > >>>> For additional commands, e-mail:
>>>>>>>> > dev-help@maven.apache.org
>>>>>>>> > >> > > > > > >>>>
>>>>>>>> > >> > > > > > >>>>
>>>>>>>> > >> > > > > >
>>>>>>>> > >> > > > > >
>>>>>>>> > >> > > > > >
>>>>>>>> > >> >
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> > >> > > > > > To unsubscribe, e-mail:
>>>>>>>> dev-unsubscribe@maven.apache.org
>>>>>>>> > >> > > > > > For additional commands, e-mail:
>>>>>>>> dev-help@maven.apache.org
>>>>>>>> > >> > > > > >
>>>>>>>> > >> > > > > >
>>>>>>>> > >> > > > >
>>>>>>>> > >> > > >
>>>>>>>> > >> > >
>>>>>>>> > >> >
>>>>>>>> > >>
>>>>>>>> > >
>>>>>>>> >
>>>>>>>>
>>>>>>>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le mar. 23 mars 2021 à 08:34, Martin Kanters <ma...@apache.org> 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 <
> rmannibucau@gmail.com>:
>
>>
>>
>> Le lun. 22 mars 2021 à 20:49, Martin Kanters <ma...@apache.org>
>> 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 <
>>> rmannibucau@gmail.com>:
>>>
>>>>
>>>>
>>>> Le lun. 22 mars 2021 à 16:07, Martin Kanters <ma...@apache.org>
>>>> 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 <
>>>>> rmannibucau@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> Le lun. 22 mars 2021 à 15:03, Martin Kanters <
>>>>>> martinkanters@apache.org> 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 <
>>>>>>> rmannibucau@gmail.com>:
>>>>>>>
>>>>>>> > 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 <
>>>>>>> rmannibucau@gmail.com>
>>>>>>> > a
>>>>>>> > écrit :
>>>>>>> >
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <
>>>>>>> rfscholte@apache.org> 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 <
>>>>>>> rmannibucau@gmail.com>
>>>>>>> > 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
>>>>>>> > >> > > rmannibucau@gmail.com>:
>>>>>>> > >> > >
>>>>>>> > >> > > > 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
>>>>>>> > >> > > > > martinkanters@apache.org>
>>>>>>> > >> > > > > > 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
>>>>>>> > >> > > > > > >> rmannibucau@gmail.com>:
>>>>>>> > >> > > > > > >>
>>>>>>> > >> > > > > > >>> 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:
>>>>>>> dev-unsubscribe@maven.apache.org
>>>>>>> > >> > > > > > >>>> For additional commands, e-mail:
>>>>>>> > dev-help@maven.apache.org
>>>>>>> > >> > > > > > >>>>
>>>>>>> > >> > > > > > >>>>
>>>>>>> > >> > > > > >
>>>>>>> > >> > > > > >
>>>>>>> > >> > > > > >
>>>>>>> > >> >
>>>>>>> ---------------------------------------------------------------------
>>>>>>> > >> > > > > > To unsubscribe, e-mail:
>>>>>>> dev-unsubscribe@maven.apache.org
>>>>>>> > >> > > > > > For additional commands, e-mail:
>>>>>>> dev-help@maven.apache.org
>>>>>>> > >> > > > > >
>>>>>>> > >> > > > > >
>>>>>>> > >> > > > >
>>>>>>> > >> > > >
>>>>>>> > >> > >
>>>>>>> > >> >
>>>>>>> > >>
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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

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 <
rmannibucau@gmail.com>:

>
>
> Le lun. 22 mars 2021 à 20:49, Martin Kanters <ma...@apache.org> 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 <
>> rmannibucau@gmail.com>:
>>
>>>
>>>
>>> Le lun. 22 mars 2021 à 16:07, Martin Kanters <ma...@apache.org>
>>> 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 <
>>>> rmannibucau@gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> Le lun. 22 mars 2021 à 15:03, Martin Kanters <ma...@apache.org>
>>>>> 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 <
>>>>>> rmannibucau@gmail.com>:
>>>>>>
>>>>>> > 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 <
>>>>>> rmannibucau@gmail.com>
>>>>>> > a
>>>>>> > écrit :
>>>>>> >
>>>>>> > >
>>>>>> > >
>>>>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <
>>>>>> rfscholte@apache.org> 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 <rmannibucau@gmail.com
>>>>>> >
>>>>>> > 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
>>>>>> > >> > > rmannibucau@gmail.com>:
>>>>>> > >> > >
>>>>>> > >> > > > 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
>>>>>> > >> > > > > martinkanters@apache.org>
>>>>>> > >> > > > > > 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
>>>>>> > >> > > > > > >> rmannibucau@gmail.com>:
>>>>>> > >> > > > > > >>
>>>>>> > >> > > > > > >>> 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:
>>>>>> dev-unsubscribe@maven.apache.org
>>>>>> > >> > > > > > >>>> For additional commands, e-mail:
>>>>>> > dev-help@maven.apache.org
>>>>>> > >> > > > > > >>>>
>>>>>> > >> > > > > > >>>>
>>>>>> > >> > > > > >
>>>>>> > >> > > > > >
>>>>>> > >> > > > > >
>>>>>> > >> >
>>>>>> ---------------------------------------------------------------------
>>>>>> > >> > > > > > To unsubscribe, e-mail:
>>>>>> dev-unsubscribe@maven.apache.org
>>>>>> > >> > > > > > For additional commands, e-mail:
>>>>>> dev-help@maven.apache.org
>>>>>> > >> > > > > >
>>>>>> > >> > > > > >
>>>>>> > >> > > > >
>>>>>> > >> > > >
>>>>>> > >> > >
>>>>>> > >> >
>>>>>> > >>
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le lun. 22 mars 2021 à 20:49, Martin Kanters <ma...@apache.org> 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 <
> rmannibucau@gmail.com>:
>
>>
>>
>> Le lun. 22 mars 2021 à 16:07, Martin Kanters <ma...@apache.org>
>> 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 <
>>> rmannibucau@gmail.com>:
>>>
>>>>
>>>>
>>>> Le lun. 22 mars 2021 à 15:03, Martin Kanters <ma...@apache.org>
>>>> 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 <
>>>>> rmannibucau@gmail.com>:
>>>>>
>>>>> > 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 <
>>>>> rmannibucau@gmail.com>
>>>>> > a
>>>>> > écrit :
>>>>> >
>>>>> > >
>>>>> > >
>>>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <
>>>>> rfscholte@apache.org> 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 <rm...@gmail.com>
>>>>> > 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
>>>>> > >> > > rmannibucau@gmail.com>:
>>>>> > >> > >
>>>>> > >> > > > 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
>>>>> > >> > > > > martinkanters@apache.org>
>>>>> > >> > > > > > 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
>>>>> > >> > > > > > >> rmannibucau@gmail.com>:
>>>>> > >> > > > > > >>
>>>>> > >> > > > > > >>> 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:
>>>>> dev-unsubscribe@maven.apache.org
>>>>> > >> > > > > > >>>> For additional commands, e-mail:
>>>>> > dev-help@maven.apache.org
>>>>> > >> > > > > > >>>>
>>>>> > >> > > > > > >>>>
>>>>> > >> > > > > >
>>>>> > >> > > > > >
>>>>> > >> > > > > >
>>>>> > >> >
>>>>> ---------------------------------------------------------------------
>>>>> > >> > > > > > To unsubscribe, e-mail:
>>>>> dev-unsubscribe@maven.apache.org
>>>>> > >> > > > > > For additional commands, e-mail:
>>>>> dev-help@maven.apache.org
>>>>> > >> > > > > >
>>>>> > >> > > > > >
>>>>> > >> > > > >
>>>>> > >> > > >
>>>>> > >> > >
>>>>> > >> >
>>>>> > >>
>>>>> > >
>>>>> >
>>>>>
>>>>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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.
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.
We can always improve later on, if we have found a better solution.

Op ma 22 mrt. 2021 om 17:51 schreef Romain Manni-Bucau <
rmannibucau@gmail.com>:

>
>
> Le lun. 22 mars 2021 à 16:07, Martin Kanters <ma...@apache.org> 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 <
>> rmannibucau@gmail.com>:
>>
>>>
>>>
>>> Le lun. 22 mars 2021 à 15:03, Martin Kanters <ma...@apache.org>
>>> 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 <
>>>> rmannibucau@gmail.com>:
>>>>
>>>> > 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 <
>>>> rmannibucau@gmail.com>
>>>> > a
>>>> > écrit :
>>>> >
>>>> > >
>>>> > >
>>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org>
>>>> 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 <rm...@gmail.com>
>>>> > 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
>>>> > >> > > rmannibucau@gmail.com>:
>>>> > >> > >
>>>> > >> > > > 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
>>>> > >> > > > > martinkanters@apache.org>
>>>> > >> > > > > > 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
>>>> > >> > > > > > >> rmannibucau@gmail.com>:
>>>> > >> > > > > > >>
>>>> > >> > > > > > >>> 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:
>>>> dev-unsubscribe@maven.apache.org
>>>> > >> > > > > > >>>> For additional commands, e-mail:
>>>> > dev-help@maven.apache.org
>>>> > >> > > > > > >>>>
>>>> > >> > > > > > >>>>
>>>> > >> > > > > >
>>>> > >> > > > > >
>>>> > >> > > > > >
>>>> > >> >
>>>> ---------------------------------------------------------------------
>>>> > >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> > >> > > > > > For additional commands, e-mail:
>>>> dev-help@maven.apache.org
>>>> > >> > > > > >
>>>> > >> > > > > >
>>>> > >> > > > >
>>>> > >> > > >
>>>> > >> > >
>>>> > >> >
>>>> > >>
>>>> > >
>>>> >
>>>>
>>>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le lun. 22 mars 2021 à 16:07, Martin Kanters <ma...@apache.org> 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 <
> rmannibucau@gmail.com>:
>
>>
>>
>> Le lun. 22 mars 2021 à 15:03, Martin Kanters <ma...@apache.org>
>> 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 <
>>> rmannibucau@gmail.com>:
>>>
>>> > 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 <
>>> rmannibucau@gmail.com>
>>> > a
>>> > écrit :
>>> >
>>> > >
>>> > >
>>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org>
>>> 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 <rm...@gmail.com>
>>> > 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
>>> > >> > > rmannibucau@gmail.com>:
>>> > >> > >
>>> > >> > > > 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
>>> > >> > > > > martinkanters@apache.org>
>>> > >> > > > > > 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
>>> > >> > > > > > >> rmannibucau@gmail.com>:
>>> > >> > > > > > >>
>>> > >> > > > > > >>> 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:
>>> dev-unsubscribe@maven.apache.org
>>> > >> > > > > > >>>> For additional commands, e-mail:
>>> > dev-help@maven.apache.org
>>> > >> > > > > > >>>>
>>> > >> > > > > > >>>>
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> >
>>> ---------------------------------------------------------------------
>>> > >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > >> > > > > > For additional commands, e-mail:
>>> dev-help@maven.apache.org
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > >
>>> > >> > > >
>>> > >> > >
>>> > >> >
>>> > >>
>>> > >
>>> >
>>>
>>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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.

By the way, -pl !xxx,yyy is still perfectly possible.

Martin

Op ma 22 mrt. 2021 om 15:47 schreef Romain Manni-Bucau <
rmannibucau@gmail.com>:

>
>
> Le lun. 22 mars 2021 à 15:03, Martin Kanters <ma...@apache.org> 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 <
>> rmannibucau@gmail.com>:
>>
>> > 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 <
>> rmannibucau@gmail.com>
>> > a
>> > écrit :
>> >
>> > >
>> > >
>> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org>
>> 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 <rm...@gmail.com>
>> > 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
>> > >> > > rmannibucau@gmail.com>:
>> > >> > >
>> > >> > > > 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
>> > >> > > > > martinkanters@apache.org>
>> > >> > > > > > 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
>> > >> > > > > > >> rmannibucau@gmail.com>:
>> > >> > > > > > >>
>> > >> > > > > > >>> 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:
>> dev-unsubscribe@maven.apache.org
>> > >> > > > > > >>>> For additional commands, e-mail:
>> > dev-help@maven.apache.org
>> > >> > > > > > >>>>
>> > >> > > > > > >>>>
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > >
>> > >> >
>> ---------------------------------------------------------------------
>> > >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le lun. 22 mars 2021 à 15:03, Martin Kanters <ma...@apache.org> 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 <
> rmannibucau@gmail.com>:
>
> > 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 <rmannibucau@gmail.com
> >
> > a
> > écrit :
> >
> > >
> > >
> > > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org> 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 <rm...@gmail.com>
> > 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
> > >> > > rmannibucau@gmail.com>:
> > >> > >
> > >> > > > 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
> > >> > > > > martinkanters@apache.org>
> > >> > > > > > 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
> > >> > > > > > >> rmannibucau@gmail.com>:
> > >> > > > > > >>
> > >> > > > > > >>> 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:
> dev-unsubscribe@maven.apache.org
> > >> > > > > > >>>> For additional commands, e-mail:
> > dev-help@maven.apache.org
> > >> > > > > > >>>>
> > >> > > > > > >>>>
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> >
> ---------------------------------------------------------------------
> > >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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,
Martin

[1] https://issues.apache.org/jira/browse/MNG-7112

Op ma 22 mrt. 2021 om 13:26 schreef Romain Manni-Bucau <
rmannibucau@gmail.com>:

> 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 <rm...@gmail.com>
> a
> écrit :
>
> >
> >
> > Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org> 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 <rm...@gmail.com>
> 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
> >> > > rmannibucau@gmail.com>:
> >> > >
> >> > > > 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
> >> > > > > martinkanters@apache.org>
> >> > > > > > 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
> >> > > > > > >> rmannibucau@gmail.com>:
> >> > > > > > >>
> >> > > > > > >>> 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: dev-unsubscribe@maven.apache.org
> >> > > > > > >>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >> > > > > > >>>>
> >> > > > > > >>>>
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > ---------------------------------------------------------------------
> >> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

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 <rm...@gmail.com> a
écrit :

>
>
> Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org> 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 <rm...@gmail.com> 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
>> > > rmannibucau@gmail.com>:
>> > >
>> > > > 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
>> > > > > martinkanters@apache.org>
>> > > > > > 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
>> > > > > > >> rmannibucau@gmail.com>:
>> > > > > > >>
>> > > > > > >>> 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: dev-unsubscribe@maven.apache.org
>> > > > > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> > > > > > >>>>
>> > > > > > >>>>
>> > > > > >
>> > > > > >
>> > > > > >
>> > ---------------------------------------------------------------------
>> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le dim. 28 févr. 2021 à 10:15, Robert Scholte <rf...@apache.org> 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 <rm...@gmail.com> 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
> > > rmannibucau@gmail.com>:
> > >
> > > > 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
> > > > > martinkanters@apache.org>
> > > > > > 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
> > > > > > >> rmannibucau@gmail.com>:
> > > > > > >>
> > > > > > >>> 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: dev-unsubscribe@maven.apache.org
> > > > > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >>>>
> > > > > > >>>>
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Robert Scholte <rf...@apache.org>]

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.

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!

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.

Robert

On 26-2-2021 14:45:18, Romain Manni-Bucau <rm...@gmail.com> 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
> > rmannibucau@gmail.com>:
> >
> > > 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
> > > > martinkanters@apache.org>
> > > > > 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
> > > > > >> rmannibucau@gmail.com>:
> > > > > >>
> > > > > >>> 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: dev-unsubscribe@maven.apache.org
> > > > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >>>>
> > > > > >>>>
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le ven. 26 févr. 2021 à 14:30, Robert Scholte <rf...@apache.org> 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 <aggregator> 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 <rm...@gmail.com> 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
> > rmannibucau@gmail.com>:
> >
> > > 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
> > > > martinkanters@apache.org>
> > > > > 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
> > > > > >> rmannibucau@gmail.com>:
> > > > > >>
> > > > > >>> 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: dev-unsubscribe@maven.apache.org
> > > > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >>>>
> > > > > >>>>
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Robert Scholte <rf...@apache.org>]

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.

Calling -pl <aggregator> with Maven3 behaves unnatural: if you want to call a specific aggregator, you want its modules to be built.

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

All the options you had in Maven 3 for selecting a subset of a multimodule project are still available in Maven 4.

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 <rm...@gmail.com> 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
> rmannibucau@gmail.com>:
>
> > 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
> > > martinkanters@apache.org>
> > > > 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
> > > > >> rmannibucau@gmail.com>:
> > > > >>
> > > > >>> 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: dev-unsubscribe@maven.apache.org
> > > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>>>
> > > > >>>>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

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 <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 ven. 26 févr. 2021 à 13:16, Martin Kanters <ma...@apache.org> 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 <
> rmannibucau@gmail.com>:
>
> > Put some comments inline but agree another minilanguage solution works.
> > Maybe -pl !!parent?
> >
> > Le dim. 21 févr. 2021 à 22:08, Martin Kanters <ma...@apache.org>
> 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): <alias><rec>-pl parent, submodule-a,
> > > submodule-b, submodule-c</rec></alias>
> > > - 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 <f....@gmx.net>:
> > >
> > > > 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 <
> > > martinkanters@apache.org>
> > > > 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 <proj>/*
> > > > >> 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 <
> > > > >> rmannibucau@gmail.com>:
> > > > >>
> > > > >>> 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> > > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>>>
> > > > >>>>
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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 <
rmannibucau@gmail.com>:

> Put some comments inline but agree another minilanguage solution works.
> Maybe -pl !!parent?
>
> Le dim. 21 févr. 2021 à 22:08, Martin Kanters <ma...@apache.org> 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): <alias><rec>-pl parent, submodule-a,
> > submodule-b, submodule-c</rec></alias>
> > - 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 <f....@gmx.net>:
> >
> > > 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 <
> > martinkanters@apache.org>
> > > 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 <proj>/*
> > > >> 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 <
> > > >> rmannibucau@gmail.com>:
> > > >>
> > > >>> 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>>>
> > > >>>>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Put some comments inline but agree another minilanguage solution works.
Maybe -pl !!parent?

Le dim. 21 févr. 2021 à 22:08, Martin Kanters <ma...@apache.org> 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): <alias><rec>-pl parent, submodule-a,
> submodule-b, submodule-c</rec></alias>
> - 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 <f....@gmx.net>:
>
> > 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 <
> martinkanters@apache.org>
> > 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 <proj>/*
> > >> 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 <
> > >> rmannibucau@gmail.com>:
> > >>
> > >>> 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>
> > >>>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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:
- pom.xml config (psuedo code): <alias><rec>-pl parent, submodule-a,
submodule-b, submodule-c</rec></alias>
- 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.

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 <f....@gmx.net>:

> 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 <ma...@apache.org>
> 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 <proj>/*
> >> 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 <
> >> rmannibucau@gmail.com>:
> >>
> >>> 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven 4: -pl !... is not recursive

[Falko Modler <f....@gmx.net>]

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 <ma...@apache.org> 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 <proj>/*
>> 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 <
>> rmannibucau@gmail.com>:
>>
>>> 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le dim. 21 févr. 2021 à 20:39, Martin Kanters <ma...@apache.org> 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 <proj>/*
> 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 <
> rmannibucau@gmail.com>:
>
> > 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

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.

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.

3. -pl <proj>/*
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.

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.

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.

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.

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.

Martin

Op za 20 feb. 2021 om 17:53 schreef Romain Manni-Bucau <
rmannibucau@gmail.com>:

> 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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

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 <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 sam. 20 févr. 2021 à 14:40, Falko Modler <f....@gmx.net> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: Maven 4: -pl !... is not recursive

[Falko Modler <f....@gmx.net>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le sam. 20 févr. 2021 à 12:43, Martin Kanters <ma...@apache.org> a
écrit :

> It would indeed be per module, so it's not a 100% backwards compatible
> workaround.
> Then again, as Robert Scholte suggested in the original discussion [1],
> does it make sense to just build an aggregator pom without its children?
>

Yes it does since it often runs validation tasks and regularly has attached
artifact(s).



> [1]
>
> https://issues.apache.org/jira/browse/MNG-6981?focusedCommentId=17192672&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17192672
>
> Op za 20 feb. 2021 om 12:32 schreef Romain Manni-Bucau <
> rmannibucau@gmail.com>:
>
> >
> >
> > Le sam. 20 févr. 2021 à 11:14, Martin Kanters <ma...@apache.org>
> > a écrit :
> >
> >> Hey,
> >>
> >> I agree this is unwanted behaviour, we should definitely align
> >> project inclusion and exclusion.
> >> In MNG-6981 [1] I made inclusion recursive. Please find the discussion
> in
> >> the JIRA comments.
> >> In summary, you can get the old behavior back using -f and -N.
> >>
> >
> > Hmm, per module? If not i would still revert for the mentionned reason
> >
> >
> >
> >> I've created MNG-7102 [2] to resolve this and will pick it up directly
> as
> >> I
> >> have also picked up MNG-6981.
> >> The only thing is that the workaround with -f and -N will not work in
> the
> >> exclusion case.
> >> I don't think it should be needed to be able to only exclude a parent
> pom,
> >> but perhaps I'm missing something.
> >> Next to that, I think we should be careful with adding new flags just to
> >> make sure we are backwards compatible, as it might unnecessarily
> >> complicate
> >> the codebase and user experience if it is not used in the end.
> >>
> >> Thanks for the bug report, Falko!
> >>
> >> Martin
> >>
> >> [1] https://issues.apache.org/jira/browse/MNG-6981
> >> [2] https://issues.apache.org/jira/browse/MNG-7102
> >>
> >> Op za 20 feb. 2021 om 10:04 schreef Markus KARG <markus@headcrashing.eu
> >:
> >>
> >> > Yes it might be the better solution to keep it backwards compatible
> and
> >> do
> >> > recursive -plr X / -plr !X as a new option.
> >> >
> >> > -----Ursprüngliche Nachricht-----
> >> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> > Gesendet: Samstag, 20. Februar 2021 09:20
> >> > An: Maven Developers List
> >> > Betreff: Re: Maven 4: -pl !... is not recursive
> >> >
> >> > Agree it should be alignde, just wonder how you handle '-N' equivalent
> >> if
> >> > -pl is recursive (so until there is a solution I'm tempting to think
> not
> >> > being recursive can be saner + at least it is backward compatible to
> v3
> >> > which is also important). If we want a recursive -pl we should
> probably
> >> add
> >> > a -plr or so IMHO.
> >> >
> >> > 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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
> >> > écrit :
> >> >
> >> > > I second that. It is counterintuitive. It would be beneficial if -pl
> >> !X
> >> > > would also exclude ist submodules.
> >> > > -Markus
> >> > >
> >> > >
> >> > > -----Ursprüngliche Nachricht-----
> >> > > Von: Falko Modler [mailto:f.modler@gmx.net]
> >> > > Gesendet: Samstag, 20. Februar 2021 01:39
> >> > > An: dev@maven.apache.org
> >> > > Betreff: Maven 4: -pl !... is not recursive
> >> > >
> >> > > Hi everyone,
> >> > >
> >> > > I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
> >> > > realized that -pl X will now also build submodules of X but -pl !X
> >> will
> >> > > only exclude X, not its submodules.
> >> > >
> >> > > Isn't this a bit inconsistent?
> >> > >
> >> > > Cheers,
> >> > >
> >> > > Falko
> >> > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >
>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

It would indeed be per module, so it's not a 100% backwards compatible
workaround.
Then again, as Robert Scholte suggested in the original discussion [1],
does it make sense to just build an aggregator pom without its children?

[1]
https://issues.apache.org/jira/browse/MNG-6981?focusedCommentId=17192672&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17192672

Op za 20 feb. 2021 om 12:32 schreef Romain Manni-Bucau <
rmannibucau@gmail.com>:

>
>
> Le sam. 20 févr. 2021 à 11:14, Martin Kanters <ma...@apache.org>
> a écrit :
>
>> Hey,
>>
>> I agree this is unwanted behaviour, we should definitely align
>> project inclusion and exclusion.
>> In MNG-6981 [1] I made inclusion recursive. Please find the discussion in
>> the JIRA comments.
>> In summary, you can get the old behavior back using -f and -N.
>>
>
> Hmm, per module? If not i would still revert for the mentionned reason
>
>
>
>> I've created MNG-7102 [2] to resolve this and will pick it up directly as
>> I
>> have also picked up MNG-6981.
>> The only thing is that the workaround with -f and -N will not work in the
>> exclusion case.
>> I don't think it should be needed to be able to only exclude a parent pom,
>> but perhaps I'm missing something.
>> Next to that, I think we should be careful with adding new flags just to
>> make sure we are backwards compatible, as it might unnecessarily
>> complicate
>> the codebase and user experience if it is not used in the end.
>>
>> Thanks for the bug report, Falko!
>>
>> Martin
>>
>> [1] https://issues.apache.org/jira/browse/MNG-6981
>> [2] https://issues.apache.org/jira/browse/MNG-7102
>>
>> Op za 20 feb. 2021 om 10:04 schreef Markus KARG <ma...@headcrashing.eu>:
>>
>> > Yes it might be the better solution to keep it backwards compatible and
>> do
>> > recursive -plr X / -plr !X as a new option.
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > Gesendet: Samstag, 20. Februar 2021 09:20
>> > An: Maven Developers List
>> > Betreff: Re: Maven 4: -pl !... is not recursive
>> >
>> > Agree it should be alignde, just wonder how you handle '-N' equivalent
>> if
>> > -pl is recursive (so until there is a solution I'm tempting to think not
>> > being recursive can be saner + at least it is backward compatible to v3
>> > which is also important). If we want a recursive -pl we should probably
>> add
>> > a -plr or so IMHO.
>> >
>> > 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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
>> > écrit :
>> >
>> > > I second that. It is counterintuitive. It would be beneficial if -pl
>> !X
>> > > would also exclude ist submodules.
>> > > -Markus
>> > >
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Falko Modler [mailto:f.modler@gmx.net]
>> > > Gesendet: Samstag, 20. Februar 2021 01:39
>> > > An: dev@maven.apache.org
>> > > Betreff: Maven 4: -pl !... is not recursive
>> > >
>> > > Hi everyone,
>> > >
>> > > I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
>> > > realized that -pl X will now also build submodules of X but -pl !X
>> will
>> > > only exclude X, not its submodules.
>> > >
>> > > Isn't this a bit inconsistent?
>> > >
>> > > Cheers,
>> > >
>> > > Falko
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > For additional commands, e-mail: dev-help@maven.apache.org
>> > >
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Le sam. 20 févr. 2021 à 11:14, Martin Kanters <ma...@apache.org> a
écrit :

> Hey,
>
> I agree this is unwanted behaviour, we should definitely align
> project inclusion and exclusion.
> In MNG-6981 [1] I made inclusion recursive. Please find the discussion in
> the JIRA comments.
> In summary, you can get the old behavior back using -f and -N.
>

Hmm, per module? If not i would still revert for the mentionned reason



> I've created MNG-7102 [2] to resolve this and will pick it up directly as I
> have also picked up MNG-6981.
> The only thing is that the workaround with -f and -N will not work in the
> exclusion case.
> I don't think it should be needed to be able to only exclude a parent pom,
> but perhaps I'm missing something.
> Next to that, I think we should be careful with adding new flags just to
> make sure we are backwards compatible, as it might unnecessarily complicate
> the codebase and user experience if it is not used in the end.
>
> Thanks for the bug report, Falko!
>
> Martin
>
> [1] https://issues.apache.org/jira/browse/MNG-6981
> [2] https://issues.apache.org/jira/browse/MNG-7102
>
> Op za 20 feb. 2021 om 10:04 schreef Markus KARG <ma...@headcrashing.eu>:
>
> > Yes it might be the better solution to keep it backwards compatible and
> do
> > recursive -plr X / -plr !X as a new option.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Samstag, 20. Februar 2021 09:20
> > An: Maven Developers List
> > Betreff: Re: Maven 4: -pl !... is not recursive
> >
> > Agree it should be alignde, just wonder how you handle '-N' equivalent if
> > -pl is recursive (so until there is a solution I'm tempting to think not
> > being recursive can be saner + at least it is backward compatible to v3
> > which is also important). If we want a recursive -pl we should probably
> add
> > a -plr or so IMHO.
> >
> > 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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
> > écrit :
> >
> > > I second that. It is counterintuitive. It would be beneficial if -pl !X
> > > would also exclude ist submodules.
> > > -Markus
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Falko Modler [mailto:f.modler@gmx.net]
> > > Gesendet: Samstag, 20. Februar 2021 01:39
> > > An: dev@maven.apache.org
> > > Betreff: Maven 4: -pl !... is not recursive
> > >
> > > Hi everyone,
> > >
> > > I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
> > > realized that -pl X will now also build submodules of X but -pl !X will
> > > only exclude X, not its submodules.
> > >
> > > Isn't this a bit inconsistent?
> > >
> > > Cheers,
> > >
> > > Falko
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

Hey,

I've created the PR to make the exclude project functionality equal to the
include project functionality.
Please find it on GitHub [1].

Martin

[1] https://github.com/apache/maven/pull/448

Op za 20 feb. 2021 om 11:14 schreef Martin Kanters <martinkanters@apache.org
>:

> Hey,
>
> I agree this is unwanted behaviour, we should definitely align
> project inclusion and exclusion.
> In MNG-6981 [1] I made inclusion recursive. Please find the discussion in
> the JIRA comments.
> In summary, you can get the old behavior back using -f and -N.
>
> I've created MNG-7102 [2] to resolve this and will pick it up directly as
> I have also picked up MNG-6981.
> The only thing is that the workaround with -f and -N will not work in the
> exclusion case.
> I don't think it should be needed to be able to only exclude a parent pom,
> but perhaps I'm missing something.
> Next to that, I think we should be careful with adding new flags just to
> make sure we are backwards compatible, as it might unnecessarily complicate
> the codebase and user experience if it is not used in the end.
>
> Thanks for the bug report, Falko!
>
> Martin
>
> [1] https://issues.apache.org/jira/browse/MNG-6981
> [2] https://issues.apache.org/jira/browse/MNG-7102
>
> Op za 20 feb. 2021 om 10:04 schreef Markus KARG <ma...@headcrashing.eu>:
>
>> Yes it might be the better solution to keep it backwards compatible and
>> do recursive -plr X / -plr !X as a new option.
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> Gesendet: Samstag, 20. Februar 2021 09:20
>> An: Maven Developers List
>> Betreff: Re: Maven 4: -pl !... is not recursive
>>
>> Agree it should be alignde, just wonder how you handle '-N' equivalent if
>> -pl is recursive (so until there is a solution I'm tempting to think not
>> being recursive can be saner + at least it is backward compatible to v3
>> which is also important). If we want a recursive -pl we should probably
>> add
>> a -plr or so IMHO.
>>
>> 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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
>> écrit :
>>
>> > I second that. It is counterintuitive. It would be beneficial if -pl !X
>> > would also exclude ist submodules.
>> > -Markus
>> >
>> >
>> > -----Ursprüngliche Nachricht-----
>> > Von: Falko Modler [mailto:f.modler@gmx.net]
>> > Gesendet: Samstag, 20. Februar 2021 01:39
>> > An: dev@maven.apache.org
>> > Betreff: Maven 4: -pl !... is not recursive
>> >
>> > Hi everyone,
>> >
>> > I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
>> > realized that -pl X will now also build submodules of X but -pl !X will
>> > only exclude X, not its submodules.
>> >
>> > Isn't this a bit inconsistent?
>> >
>> > Cheers,
>> >
>> > Falko
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

Re: Maven 4: -pl !... is not recursive

[Martin Kanters <ma...@apache.org>]

Hey,

I agree this is unwanted behaviour, we should definitely align
project inclusion and exclusion.
In MNG-6981 [1] I made inclusion recursive. Please find the discussion in
the JIRA comments.
In summary, you can get the old behavior back using -f and -N.

I've created MNG-7102 [2] to resolve this and will pick it up directly as I
have also picked up MNG-6981.
The only thing is that the workaround with -f and -N will not work in the
exclusion case.
I don't think it should be needed to be able to only exclude a parent pom,
but perhaps I'm missing something.
Next to that, I think we should be careful with adding new flags just to
make sure we are backwards compatible, as it might unnecessarily complicate
the codebase and user experience if it is not used in the end.

Thanks for the bug report, Falko!

Martin

[1] https://issues.apache.org/jira/browse/MNG-6981
[2] https://issues.apache.org/jira/browse/MNG-7102

Op za 20 feb. 2021 om 10:04 schreef Markus KARG <ma...@headcrashing.eu>:

> Yes it might be the better solution to keep it backwards compatible and do
> recursive -plr X / -plr !X as a new option.
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Samstag, 20. Februar 2021 09:20
> An: Maven Developers List
> Betreff: Re: Maven 4: -pl !... is not recursive
>
> Agree it should be alignde, just wonder how you handle '-N' equivalent if
> -pl is recursive (so until there is a solution I'm tempting to think not
> being recursive can be saner + at least it is backward compatible to v3
> which is also important). If we want a recursive -pl we should probably add
> a -plr or so IMHO.
>
> 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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
> écrit :
>
> > I second that. It is counterintuitive. It would be beneficial if -pl !X
> > would also exclude ist submodules.
> > -Markus
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Falko Modler [mailto:f.modler@gmx.net]
> > Gesendet: Samstag, 20. Februar 2021 01:39
> > An: dev@maven.apache.org
> > Betreff: Maven 4: -pl !... is not recursive
> >
> > Hi everyone,
> >
> > I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
> > realized that -pl X will now also build submodules of X but -pl !X will
> > only exclude X, not its submodules.
> >
> > Isn't this a bit inconsistent?
> >
> > Cheers,
> >
> > Falko
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

AW: Maven 4: -pl !... is not recursive

[Markus KARG <ma...@headcrashing.eu>]

Yes it might be the better solution to keep it backwards compatible and do recursive -plr X / -plr !X as a new option.

-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com] 
Gesendet: Samstag, 20. Februar 2021 09:20
An: Maven Developers List
Betreff: Re: Maven 4: -pl !... is not recursive

Agree it should be alignde, just wonder how you handle '-N' equivalent if
-pl is recursive (so until there is a solution I'm tempting to think not
being recursive can be saner + at least it is backward compatible to v3
which is also important). If we want a recursive -pl we should probably add
a -plr or so IMHO.

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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
écrit :

> I second that. It is counterintuitive. It would be beneficial if -pl !X
> would also exclude ist submodules.
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Falko Modler [mailto:f.modler@gmx.net]
> Gesendet: Samstag, 20. Februar 2021 01:39
> An: dev@maven.apache.org
> Betreff: Maven 4: -pl !... is not recursive
>
> Hi everyone,
>
> I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
> realized that -pl X will now also build submodules of X but -pl !X will
> only exclude X, not its submodules.
>
> Isn't this a bit inconsistent?
>
> Cheers,
>
> Falko
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Maven 4: -pl !... is not recursive

[Romain Manni-Bucau <rm...@gmail.com>]

Agree it should be alignde, just wonder how you handle '-N' equivalent if
-pl is recursive (so until there is a solution I'm tempting to think not
being recursive can be saner + at least it is backward compatible to v3
which is also important). If we want a recursive -pl we should probably add
a -plr or so IMHO.

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 sam. 20 févr. 2021 à 09:14, Markus KARG <ma...@headcrashing.eu> a
écrit :

> I second that. It is counterintuitive. It would be beneficial if -pl !X
> would also exclude ist submodules.
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Falko Modler [mailto:f.modler@gmx.net]
> Gesendet: Samstag, 20. Februar 2021 01:39
> An: dev@maven.apache.org
> Betreff: Maven 4: -pl !... is not recursive
>
> Hi everyone,
>
> I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
> realized that -pl X will now also build submodules of X but -pl !X will
> only exclude X, not its submodules.
>
> Isn't this a bit inconsistent?
>
> Cheers,
>
> Falko
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

AW: Maven 4: -pl !... is not recursive

[Markus KARG <ma...@headcrashing.eu>]

I second that. It is counterintuitive. It would be beneficial if -pl !X would also exclude ist submodules.
-Markus


-----Ursprüngliche Nachricht-----
Von: Falko Modler [mailto:f.modler@gmx.net] 
Gesendet: Samstag, 20. Februar 2021 01:39
An: dev@maven.apache.org
Betreff: Maven 4: -pl !... is not recursive

Hi everyone,

I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I
realized that -pl X will now also build submodules of X but -pl !X will
only exclude X, not its submodules.

Isn't this a bit inconsistent?

Cheers,

Falko


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org