You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Michael Osipov <mi...@apache.org> on 2016/06/13 22:16:44 UTC
Edge case in artifact filtering algorithm
Hi folks,
I am currently investigating
https://issues.apache.org/jira/browse/MASSEMBLY-809
After an analysis, I came to the conclusion that Maven Common Artifact
Filters apply include filters telescopic for non-wildcard patterns.
Consider this in the assembly.xml [1]:
....
<include>test.project:project:jar</include>
....
The dependency list contains:
1. test.project:project:jar
2. test.project:project:jar:doc
PatternIncludesArtifactFilter says that both artifacts match that
pattern while *:jar matches only the first one. It does not feel right
to me that *all* classifiers are included if none is given compared to
wildcard ones [2].
Is this a shortcoming of our MASSEMBLY documentation or a bug in the
shared component?
[1]
https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
[2]
http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Edge case in artifact filtering algorithm
Posted by Robert Scholte <rf...@apache.org>.
Hi,
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
patterns as described on this page look okay to me.
So maybe it is not that hard to switch
Robert
On Wed, 15 Jun 2016 19:59:26 +0200, Robert Scholte <rf...@apache.org>
wrote:
> On Wed, 15 Jun 2016 00:02:47 +0200, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2016-06-14 um 23:45 schrieb Robert Scholte:
>>> too much fun to fix this.
>>>
>>> http://svn.apache.org/viewvc?rev=1748472&view=rev should do the trick.
>>>
>>> Still some doc updates required
>>
>> Good! We still must take great care because throughout several places
>> in Aether and Maven coords format with colon might not be consistent
>> after artifactId. For MASSEMBLY, the classifier comes after type and is
>> optional.
>>
>
> I'm aware of that. I'd prefer to use the Aether pattern for the filters
> to keep it less complex. If plugins want/need to use other patterns it's
> up to them, but maybe 3.0 is the right moment to start consistency.
>
> Robert
>>> On Tue, 14 Jun 2016 22:10:30 +0200, Robert Scholte
>>> <rf...@apache.org> wrote:
>>>
>>>> On Tue, 14 Jun 2016 18:59:50 +0200, Michael Osipov
>>>> <mi...@apache.org> wrote:
>>>>
>>>>> Am 2016-06-14 um 17:34 schrieb Robert Scholte:
>>>>>> I think we're making it ourself very hard if we keep supporting
>>>>>> :jar.
>>>>>> I would have read it as any groupId + artifactId='jar'.
>>>>>> Instead with 3.0 we should switch to the patterns as defined by
>>>>>> Aether[1]; no need to maintain assembly specific patterns, use them
>>>>>> as
>>>>>> is with Aether.
>>>>>> WDYT?
>>>>>
>>>>> I agree here. We need less magic and more predictability.
>>>>>
>>>>>> [1]
>>>>>> http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
>>>>>>
>>>>>
>>>>> It pretty much look like before without omission from left-hard site.
>>>>> There is, though, a flaw. I see no classifier support and this is
>>>>> crucial for the assembly plugin.
>>>>>
>>>>
>>>> That's kind of a surprise. Sure, classifier is optional, but I think
>>>> it would make sense to have the a pattern including classifier as
>>>> well.
>>>>
>>>> g:a:v:e[:c]
>>>>
>>>> It shouldn't be too hard to embed this in the shared component
>>>> maven-common-artifact-filters so it'll work for both Aether
>>>> implementations.
>>>>
>>>> Robert
>>>>
>>>>
>>>>> Michael
>>>>>
>>>>>> On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov
>>>>>> <mi...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> I am currently investigating
>>>>>>> https://issues.apache.org/jira/browse/MASSEMBLY-809
>>>>>>>
>>>>>>> After an analysis, I came to the conclusion that Maven Common
>>>>>>> Artifact
>>>>>>> Filters apply include filters telescopic for non-wildcard patterns.
>>>>>>>
>>>>>>> Consider this in the assembly.xml [1]:
>>>>>>>
>>>>>>> ....
>>>>>>> <include>test.project:project:jar</include>
>>>>>>> ....
>>>>>>>
>>>>>>> The dependency list contains:
>>>>>>> 1. test.project:project:jar
>>>>>>> 2. test.project:project:jar:doc
>>>>>>>
>>>>>>> PatternIncludesArtifactFilter says that both artifacts match that
>>>>>>> pattern while *:jar matches only the first one. It does not feel
>>>>>>> right
>>>>>>> to me that *all* classifiers are included if none is given
>>>>>>> compared to
>>>>>>> wildcard ones [2].
>>>>>>>
>>>>>>> Is this a shortcoming of our MASSEMBLY documentation or a bug in
>>>>>>> the
>>>>>>> shared component?
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>>>>>> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>> ---------------------------------------------------------------------
>>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Edge case in artifact filtering algorithm
Posted by Robert Scholte <rf...@apache.org>.
On Wed, 15 Jun 2016 00:02:47 +0200, Michael Osipov <mi...@apache.org>
wrote:
> Am 2016-06-14 um 23:45 schrieb Robert Scholte:
>> too much fun to fix this.
>>
>> http://svn.apache.org/viewvc?rev=1748472&view=rev should do the trick.
>>
>> Still some doc updates required
>
> Good! We still must take great care because throughout several places in
> Aether and Maven coords format with colon might not be consistent after
> artifactId. For MASSEMBLY, the classifier comes after type and is
> optional.
>
I'm aware of that. I'd prefer to use the Aether pattern for the filters to
keep it less complex. If plugins want/need to use other patterns it's up
to them, but maybe 3.0 is the right moment to start consistency.
Robert
>> On Tue, 14 Jun 2016 22:10:30 +0200, Robert Scholte
>> <rf...@apache.org> wrote:
>>
>>> On Tue, 14 Jun 2016 18:59:50 +0200, Michael Osipov
>>> <mi...@apache.org> wrote:
>>>
>>>> Am 2016-06-14 um 17:34 schrieb Robert Scholte:
>>>>> I think we're making it ourself very hard if we keep supporting :jar.
>>>>> I would have read it as any groupId + artifactId='jar'.
>>>>> Instead with 3.0 we should switch to the patterns as defined by
>>>>> Aether[1]; no need to maintain assembly specific patterns, use them
>>>>> as
>>>>> is with Aether.
>>>>> WDYT?
>>>>
>>>> I agree here. We need less magic and more predictability.
>>>>
>>>>> [1]
>>>>> http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
>>>>>
>>>>
>>>> It pretty much look like before without omission from left-hard site.
>>>> There is, though, a flaw. I see no classifier support and this is
>>>> crucial for the assembly plugin.
>>>>
>>>
>>> That's kind of a surprise. Sure, classifier is optional, but I think
>>> it would make sense to have the a pattern including classifier as well.
>>>
>>> g:a:v:e[:c]
>>>
>>> It shouldn't be too hard to embed this in the shared component
>>> maven-common-artifact-filters so it'll work for both Aether
>>> implementations.
>>>
>>> Robert
>>>
>>>
>>>> Michael
>>>>
>>>>> On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov
>>>>> <mi...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> I am currently investigating
>>>>>> https://issues.apache.org/jira/browse/MASSEMBLY-809
>>>>>>
>>>>>> After an analysis, I came to the conclusion that Maven Common
>>>>>> Artifact
>>>>>> Filters apply include filters telescopic for non-wildcard patterns.
>>>>>>
>>>>>> Consider this in the assembly.xml [1]:
>>>>>>
>>>>>> ....
>>>>>> <include>test.project:project:jar</include>
>>>>>> ....
>>>>>>
>>>>>> The dependency list contains:
>>>>>> 1. test.project:project:jar
>>>>>> 2. test.project:project:jar:doc
>>>>>>
>>>>>> PatternIncludesArtifactFilter says that both artifacts match that
>>>>>> pattern while *:jar matches only the first one. It does not feel
>>>>>> right
>>>>>> to me that *all* classifiers are included if none is given compared
>>>>>> to
>>>>>> wildcard ones [2].
>>>>>>
>>>>>> Is this a shortcoming of our MASSEMBLY documentation or a bug in the
>>>>>> shared component?
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
>>>>>>
>>>>>>
>>>>>> [2]
>>>>>> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>>>>>>
>>>>>>
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Edge case in artifact filtering algorithm
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-06-14 um 23:45 schrieb Robert Scholte:
> too much fun to fix this.
>
> http://svn.apache.org/viewvc?rev=1748472&view=rev should do the trick.
>
> Still some doc updates required
Good! We still must take great care because throughout several places in
Aether and Maven coords format with colon might not be consistent after
artifactId. For MASSEMBLY, the classifier comes after type and is optional.
> On Tue, 14 Jun 2016 22:10:30 +0200, Robert Scholte
> <rf...@apache.org> wrote:
>
>> On Tue, 14 Jun 2016 18:59:50 +0200, Michael Osipov
>> <mi...@apache.org> wrote:
>>
>>> Am 2016-06-14 um 17:34 schrieb Robert Scholte:
>>>> I think we're making it ourself very hard if we keep supporting :jar.
>>>> I would have read it as any groupId + artifactId='jar'.
>>>> Instead with 3.0 we should switch to the patterns as defined by
>>>> Aether[1]; no need to maintain assembly specific patterns, use them as
>>>> is with Aether.
>>>> WDYT?
>>>
>>> I agree here. We need less magic and more predictability.
>>>
>>>> [1]
>>>> http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
>>>>
>>>
>>> It pretty much look like before without omission from left-hard site.
>>> There is, though, a flaw. I see no classifier support and this is
>>> crucial for the assembly plugin.
>>>
>>
>> That's kind of a surprise. Sure, classifier is optional, but I think
>> it would make sense to have the a pattern including classifier as well.
>>
>> g:a:v:e[:c]
>>
>> It shouldn't be too hard to embed this in the shared component
>> maven-common-artifact-filters so it'll work for both Aether
>> implementations.
>>
>> Robert
>>
>>
>>> Michael
>>>
>>>> On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov
>>>> <mi...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> I am currently investigating
>>>>> https://issues.apache.org/jira/browse/MASSEMBLY-809
>>>>>
>>>>> After an analysis, I came to the conclusion that Maven Common Artifact
>>>>> Filters apply include filters telescopic for non-wildcard patterns.
>>>>>
>>>>> Consider this in the assembly.xml [1]:
>>>>>
>>>>> ....
>>>>> <include>test.project:project:jar</include>
>>>>> ....
>>>>>
>>>>> The dependency list contains:
>>>>> 1. test.project:project:jar
>>>>> 2. test.project:project:jar:doc
>>>>>
>>>>> PatternIncludesArtifactFilter says that both artifacts match that
>>>>> pattern while *:jar matches only the first one. It does not feel right
>>>>> to me that *all* classifiers are included if none is given compared to
>>>>> wildcard ones [2].
>>>>>
>>>>> Is this a shortcoming of our MASSEMBLY documentation or a bug in the
>>>>> shared component?
>>>>>
>>>>> [1]
>>>>> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
>>>>>
>>>>>
>>>>> [2]
>>>>> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>>>>>
>>>>>
>>>>>
>>>>> Michael
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
> ---------------------------------------------------------------------
> 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: Edge case in artifact filtering algorithm
Posted by Robert Scholte <rf...@apache.org>.
too much fun to fix this.
http://svn.apache.org/viewvc?rev=1748472&view=rev should do the trick.
Still some doc updates required
Robert
On Tue, 14 Jun 2016 22:10:30 +0200, Robert Scholte <rf...@apache.org>
wrote:
> On Tue, 14 Jun 2016 18:59:50 +0200, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2016-06-14 um 17:34 schrieb Robert Scholte:
>>> I think we're making it ourself very hard if we keep supporting :jar.
>>> I would have read it as any groupId + artifactId='jar'.
>>> Instead with 3.0 we should switch to the patterns as defined by
>>> Aether[1]; no need to maintain assembly specific patterns, use them as
>>> is with Aether.
>>> WDYT?
>>
>> I agree here. We need less magic and more predictability.
>>
>>> [1]
>>> http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
>>
>> It pretty much look like before without omission from left-hard site.
>> There is, though, a flaw. I see no classifier support and this is
>> crucial for the assembly plugin.
>>
>
> That's kind of a surprise. Sure, classifier is optional, but I think it
> would make sense to have the a pattern including classifier as well.
>
> g:a:v:e[:c]
>
> It shouldn't be too hard to embed this in the shared component
> maven-common-artifact-filters so it'll work for both Aether
> implementations.
>
> Robert
>
>
>> Michael
>>
>>> On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov
>>> <mi...@apache.org>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I am currently investigating
>>>> https://issues.apache.org/jira/browse/MASSEMBLY-809
>>>>
>>>> After an analysis, I came to the conclusion that Maven Common Artifact
>>>> Filters apply include filters telescopic for non-wildcard patterns.
>>>>
>>>> Consider this in the assembly.xml [1]:
>>>>
>>>> ....
>>>> <include>test.project:project:jar</include>
>>>> ....
>>>>
>>>> The dependency list contains:
>>>> 1. test.project:project:jar
>>>> 2. test.project:project:jar:doc
>>>>
>>>> PatternIncludesArtifactFilter says that both artifacts match that
>>>> pattern while *:jar matches only the first one. It does not feel right
>>>> to me that *all* classifiers are included if none is given compared to
>>>> wildcard ones [2].
>>>>
>>>> Is this a shortcoming of our MASSEMBLY documentation or a bug in the
>>>> shared component?
>>>>
>>>> [1]
>>>> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
>>>>
>>>> [2]
>>>> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>>>>
>>>>
>>>> Michael
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Edge case in artifact filtering algorithm
Posted by Robert Scholte <rf...@apache.org>.
On Tue, 14 Jun 2016 18:59:50 +0200, Michael Osipov <mi...@apache.org>
wrote:
> Am 2016-06-14 um 17:34 schrieb Robert Scholte:
>> I think we're making it ourself very hard if we keep supporting :jar.
>> I would have read it as any groupId + artifactId='jar'.
>> Instead with 3.0 we should switch to the patterns as defined by
>> Aether[1]; no need to maintain assembly specific patterns, use them as
>> is with Aether.
>> WDYT?
>
> I agree here. We need less magic and more predictability.
>
>> [1]
>> http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
>
> It pretty much look like before without omission from left-hard site.
> There is, though, a flaw. I see no classifier support and this is
> crucial for the assembly plugin.
>
That's kind of a surprise. Sure, classifier is optional, but I think it
would make sense to have the a pattern including classifier as well.
g:a:v:e[:c]
It shouldn't be too hard to embed this in the shared component
maven-common-artifact-filters so it'll work for both Aether
implementations.
Robert
> Michael
>
>> On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov <mi...@apache.org>
>> wrote:
>>
>>> Hi folks,
>>>
>>> I am currently investigating
>>> https://issues.apache.org/jira/browse/MASSEMBLY-809
>>>
>>> After an analysis, I came to the conclusion that Maven Common Artifact
>>> Filters apply include filters telescopic for non-wildcard patterns.
>>>
>>> Consider this in the assembly.xml [1]:
>>>
>>> ....
>>> <include>test.project:project:jar</include>
>>> ....
>>>
>>> The dependency list contains:
>>> 1. test.project:project:jar
>>> 2. test.project:project:jar:doc
>>>
>>> PatternIncludesArtifactFilter says that both artifacts match that
>>> pattern while *:jar matches only the first one. It does not feel right
>>> to me that *all* classifiers are included if none is given compared to
>>> wildcard ones [2].
>>>
>>> Is this a shortcoming of our MASSEMBLY documentation or a bug in the
>>> shared component?
>>>
>>> [1]
>>> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
>>>
>>> [2]
>>> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>>>
>>>
>>> Michael
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: Edge case in artifact filtering algorithm
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-06-14 um 17:34 schrieb Robert Scholte:
> I think we're making it ourself very hard if we keep supporting :jar.
> I would have read it as any groupId + artifactId='jar'.
> Instead with 3.0 we should switch to the patterns as defined by
> Aether[1]; no need to maintain assembly specific patterns, use them as
> is with Aether.
> WDYT?
I agree here. We need less magic and more predictability.
> [1]
> http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
It pretty much look like before without omission from left-hard site.
There is, though, a flaw. I see no classifier support and this is
crucial for the assembly plugin.
Michael
> On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Hi folks,
>>
>> I am currently investigating
>> https://issues.apache.org/jira/browse/MASSEMBLY-809
>>
>> After an analysis, I came to the conclusion that Maven Common Artifact
>> Filters apply include filters telescopic for non-wildcard patterns.
>>
>> Consider this in the assembly.xml [1]:
>>
>> ....
>> <include>test.project:project:jar</include>
>> ....
>>
>> The dependency list contains:
>> 1. test.project:project:jar
>> 2. test.project:project:jar:doc
>>
>> PatternIncludesArtifactFilter says that both artifacts match that
>> pattern while *:jar matches only the first one. It does not feel right
>> to me that *all* classifiers are included if none is given compared to
>> wildcard ones [2].
>>
>> Is this a shortcoming of our MASSEMBLY documentation or a bug in the
>> shared component?
>>
>> [1]
>> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
>>
>> [2]
>> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>>
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Edge case in artifact filtering algorithm
Posted by Robert Scholte <rf...@apache.org>.
I think we're making it ourself very hard if we keep supporting :jar.
I would have read it as any groupId + artifactId='jar'.
Instead with 3.0 we should switch to the patterns as defined by Aether[1];
no need to maintain assembly specific patterns, use them as is with Aether.
WDYT?
Robert
[1]
http://download.eclipse.org/aether/aether-core/1.0.0/apidocs/index.html?org/eclipse/aether/util/filter/PatternExclusionsDependencyFilter.html
On Tue, 14 Jun 2016 00:16:44 +0200, Michael Osipov <mi...@apache.org>
wrote:
> Hi folks,
>
> I am currently investigating
> https://issues.apache.org/jira/browse/MASSEMBLY-809
>
> After an analysis, I came to the conclusion that Maven Common Artifact
> Filters apply include filters telescopic for non-wildcard patterns.
>
> Consider this in the assembly.xml [1]:
>
> ....
> <include>test.project:project:jar</include>
> ....
>
> The dependency list contains:
> 1. test.project:project:jar
> 2. test.project:project:jar:doc
>
> PatternIncludesArtifactFilter says that both artifacts match that
> pattern while *:jar matches only the first one. It does not feel right
> to me that *all* classifiers are included if none is given compared to
> wildcard ones [2].
>
> Is this a shortcoming of our MASSEMBLY documentation or a bug in the
> shared component?
>
> [1]
> https://github.com/ochaloup/reproducer-massebly-809/blob/master/assembly/distro.xml
> [2]
> http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html#Advanced_Artifact-Matching_in_includes_and_excludes
>
> Michael
>
> ---------------------------------------------------------------------
> 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