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