maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Second MNG-6713
Date Sat, 27 Jul 2019 11:08:47 GMT
Il sab 27 lug 2019, 12:52 Robert Scholte <rfscholte@apache.org> ha scritto:

> On Sat, 27 Jul 2019 11:52:21 +0200, Enrico Olivelli <eolivelli@gmail.com>
>
> wrote:
>
> > Il gio 25 lug 2019, 09:33 Alexius Diakogiannis <
> > alexius.diakogiannis@gmail.com> 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 <
> >> robert.scholte@sourcegrounds.nl> 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: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message