Le lun. 22 mars 2021 à 20:49, Martin Kanters <martinkant...@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 <
> 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
>>>>> > >> > > > > >
>>>>> > >> > > > > >
>>>>> > >> > > > >
>>>>> > >> > > >
>>>>> > >> > >
>>>>> > >> >
>>>>> > >>
>>>>> > >
>>>>> >
>>>>>
>>>>
