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