Err, let's keep using examples to avoid miscommunication :p If I understand you correctly, you mean this:
root: ... images: ........ image-a ........ image-b ... assemblies: ........ assembly-a ........ assembly-b When running from root, you can use: > mvn <goal> -pl !root,!images,!assemblies -N This will build image-a, image-b, assembly-a, assembly-b. It skips all three aggregators. By the way, -pl !xxx,yyy is still perfectly possible. Martin Op ma 22 mrt. 2021 om 15:47 schreef Romain Manni-Bucau < 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 >> > >> > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > >> > >> > >> >> > > >> > >> >
