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