You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <ro...@sourcegrounds.nl> on 2019/07/24 19:38:31 UTC
Second MNG-6713
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
[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
Re: Second MNG-6713
Posted by Enrico Olivelli <eo...@gmail.com>.
Il sab 27 lug 2019, 12:52 Robert Scholte <rf...@apache.org> ha scritto:
> On Sat, 27 Jul 2019 11:52:21 +0200, Enrico Olivelli <eo...@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
>
>
Re: Second MNG-6713
Posted by Robert Scholte <rf...@apache.org>.
On Sat, 27 Jul 2019 11:52:21 +0200, Enrico Olivelli <eo...@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.
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
Re: Second MNG-6713
Posted by Enrico Olivelli <eo...@gmail.com>.
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>
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
> >
> >
>
Re: Second MNG-6713
Posted by Alexius Diakogiannis <al...@gmail.com>.
Hi,
In my honest opinion it does, in case you want to switch from artifacts
that belong to a migrated groupid.
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
>
>