Le sam. 20 févr. 2021 à 12:43, Martin Kanters <martinkant...@apache.org> a écrit :
> It would indeed be per module, so it's not a 100% backwards compatible > workaround. > Then again, as Robert Scholte suggested in the original discussion [1], > does it make sense to just build an aggregator pom without its children? > Yes it does since it often runs validation tasks and regularly has attached artifact(s). > [1] > > https://issues.apache.org/jira/browse/MNG-6981?focusedCommentId=17192672&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17192672 > > Op za 20 feb. 2021 om 12:32 schreef Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > > Le sam. 20 févr. 2021 à 11:14, Martin Kanters <martinkant...@apache.org> > > a écrit : > > > >> Hey, > >> > >> I agree this is unwanted behaviour, we should definitely align > >> project inclusion and exclusion. > >> In MNG-6981 [1] I made inclusion recursive. Please find the discussion > in > >> the JIRA comments. > >> In summary, you can get the old behavior back using -f and -N. > >> > > > > Hmm, per module? If not i would still revert for the mentionned reason > > > > > > > >> I've created MNG-7102 [2] to resolve this and will pick it up directly > as > >> I > >> have also picked up MNG-6981. > >> The only thing is that the workaround with -f and -N will not work in > the > >> exclusion case. > >> I don't think it should be needed to be able to only exclude a parent > pom, > >> but perhaps I'm missing something. > >> Next to that, I think we should be careful with adding new flags just to > >> make sure we are backwards compatible, as it might unnecessarily > >> complicate > >> the codebase and user experience if it is not used in the end. > >> > >> Thanks for the bug report, Falko! > >> > >> Martin > >> > >> [1] https://issues.apache.org/jira/browse/MNG-6981 > >> [2] https://issues.apache.org/jira/browse/MNG-7102 > >> > >> Op za 20 feb. 2021 om 10:04 schreef Markus KARG <mar...@headcrashing.eu > >: > >> > >> > Yes it might be the better solution to keep it backwards compatible > and > >> do > >> > recursive -plr X / -plr !X as a new option. > >> > > >> > -----Ursprüngliche Nachricht----- > >> > Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] > >> > Gesendet: Samstag, 20. Februar 2021 09:20 > >> > An: Maven Developers List > >> > Betreff: Re: Maven 4: -pl !... is not recursive > >> > > >> > Agree it should be alignde, just wonder how you handle '-N' equivalent > >> if > >> > -pl is recursive (so until there is a solution I'm tempting to think > not > >> > being recursive can be saner + at least it is backward compatible to > v3 > >> > which is also important). If we want a recursive -pl we should > probably > >> add > >> > a -plr or so IMHO. > >> > > >> > 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 sam. 20 févr. 2021 à 09:14, Markus KARG <mar...@headcrashing.eu> a > >> > écrit : > >> > > >> > > I second that. It is counterintuitive. It would be beneficial if -pl > >> !X > >> > > would also exclude ist submodules. > >> > > -Markus > >> > > > >> > > > >> > > -----Ursprüngliche Nachricht----- > >> > > Von: Falko Modler [mailto:f.mod...@gmx.net] > >> > > Gesendet: Samstag, 20. Februar 2021 01:39 > >> > > An: dev@maven.apache.org > >> > > Betreff: Maven 4: -pl !... is not recursive > >> > > > >> > > Hi everyone, > >> > > > >> > > I started playing around with 4.0.0-alpha-1-20210214.163053-40 and I > >> > > realized that -pl X will now also build submodules of X but -pl !X > >> will > >> > > only exclude X, not its submodules. > >> > > > >> > > Isn't this a bit inconsistent? > >> > > > >> > > 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 > >> > > > >> > > > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >> > > >> > > >
