Il sab 27 lug 2019, 12:52 Robert Scholte <[email protected]> ha scritto:
> On Sat, 27 Jul 2019 11:52:21 +0200, Enrico Olivelli <[email protected]> > > wrote: > > > Il gio 25 lug 2019, 09:33 Alexius Diakogiannis < > > [email protected]> ha scritto: > > > >> Hi, > >> > >> In my honest opinion it does, in case you want to switch from artifacts > >> that belong to a migrated groupid. > >> > > > > It may have sense, but it is very corner case. > > I have never seen such cases. > > > > It would be interesting to have some 'exclude * except ...' > > > > Like > > <exclusion> > > <groupid>io.netty</groupid> > > <artifactId>* but keep netty-all<artifactId> > > </exclusion> > > I don't think we should do something like this. In Maven we have includes > to define a set of dependencies and excludes to remove some specific > dependencies. Adding another layer would overcomplicate things. > Robert, You are right and your example is what people usually do. And I agree is it better. I was just thinking out loud. Thanks for your reply. Enrico > Instead, people could do: > <dependency> > <groupId>GROUPID</groupId> > <artifactId>ARTIFACT</artifactId> > <exclusions> > <exclusion> > <groupid>io.netty</groupid> > <artifactId>*<artifactId> > </exclusion> > </exclusions> > </dependency> > <dependency> > <groupId>io.netty</groupId> > <artifactId>netty-all</artifactId> > </dependency> > > > > > Netty is famous for shipping a uber netty-all and a ten of netty-codec, > > netty-common...artifacts and it is always a mess to keep clean the > > dependency tree in case of multiple consumers of such library in > > different > > flavours (uber vs split) > > > > Sorry for beeing slightly off topic > > > > I will review the patch > > > > Enrico > > > > > > > >> Thanks, > >> Alexius > >> > >> > >> On Thu, 25 Jul 2019 at 10:29, Robert Scholte < > >> [email protected]> wrote: > >> > >> > At JCrete I've been working with Ray Tsang on some issues with > >> enforcer > >> > rules that didn't respect the exclusions of dependencies. > >> > After digging a log we discovered that the real issue is the > >> > ExclusionFilter, which isn't aware of wildcard exclusions. > >> > So the fix was quite easy[1] > >> > The funny thing is that the original IncludesArtifactFilter (3.6.0 and > >> > before) had a todo comment regarding wildcards[2] > >> > With MNG-6713[3] several enforcer rules are fixed automatically, > >> without > >> > any codechange! > >> > > >> > As long as master is still unstable, it is hard to confirm this change > >> > doesn't cause any regression. > >> > > >> > One thing worth mentioning (as the wildcards are never explicitly > >> > specified): > >> > Does it make sense to have a wildcard from groupId and an explicit > >> value > >> > for artifactId? > >> > Current proposal allows it. > >> > > >> > thanks, > >> > Robert > >> > > >> > [1] https://github.com/apache/maven/pull/269 > >> > [2] > >> > > >> > > >> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/ > >> > IncludesArtifactFilter.java#L52 > >> > < > >> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/artifact/resolver/filter/IncludesArtifactFilter.java#L52 > >> > > >> > [3] https://issues.apache.org/jira/browse/MNG-6713 > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
