You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Kamil Jarosz (Jira)" <ji...@apache.org> on 2023/09/12 09:23:00 UTC
[jira] [Updated] (MSHARED-1300) Order of dependencies is not always retained when filtering
[ https://issues.apache.org/jira/browse/MSHARED-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kamil Jarosz updated MSHARED-1300:
----------------------------------
Description:
{{AbstractArtifactFeatureFilter}} does not retain the order of dependencies when filtering using multiple includes. The dependencies will be ordered first by their respective includes.
For instance when filtering the following set of dependencies using {{org.apache.maven.shared.artifact.filter.collection.TypeFilter}}
{code:java}
com.example:dependency-a:jar:1.0
com.example:dependency-b:war:1.0
com.example:dependency-c:zip:1.0
{code}
with includes {{zip,jar}} and excludes {{{}war{}}}, I will get the following:
{code:java}
com.example:dependency-c:zip:1.0
com.example:dependency-a:jar:1.0
{code}
where dependencies are ordered by their type according to the the includes. I would expect that the filter retains the original order of dependencies, irrespective of the order of includes, i.e.
{code:java}
com.example:dependency-a:jar:1.0
com.example:dependency-c:zip:1.0
{code}
This is caused by an invalid order of loops in {{{}org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter#filterIncludes{}}}, where includes are traversed first instead of artifacts.
was:
{{AbstractArtifactFeatureFilter}} does not retain order of dependencies when filtering using multiple includes. The dependencies will be ordered first by their respective includes.
For instance when filtering the following set of dependencies using {{org.apache.maven.shared.artifact.filter.collection.TypeFilter}}
{code:java}
com.example:dependency-a:jar:1.0
com.example:dependency-b:war:1.0
com.example:dependency-c:zip:1.0
{code}
with includes {{zip,jar}} and excludes {{{}war{}}}, I will get the following:
{code:java}
com.example:dependency-c:zip:1.0
com.example:dependency-a:jar:1.0
{code}
Where dependencies are ordered by their type according to the the includes. I would expect that the filter retains the original order of dependencies, irrespective of the order of includes, i.e.
{code:java}
com.example:dependency-a:jar:1.0
com.example:dependency-c:zip:1.0
{code}
This is caused by an invalid order of loops in {{{}org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter#filterIncludes{}}}, where includes are traversed first instead of artifacts.
> Order of dependencies is not always retained when filtering
> -----------------------------------------------------------
>
> Key: MSHARED-1300
> URL: https://issues.apache.org/jira/browse/MSHARED-1300
> Project: Maven Shared Components
> Issue Type: Bug
> Reporter: Kamil Jarosz
> Priority: Major
>
> {{AbstractArtifactFeatureFilter}} does not retain the order of dependencies when filtering using multiple includes. The dependencies will be ordered first by their respective includes.
> For instance when filtering the following set of dependencies using {{org.apache.maven.shared.artifact.filter.collection.TypeFilter}}
> {code:java}
> com.example:dependency-a:jar:1.0
> com.example:dependency-b:war:1.0
> com.example:dependency-c:zip:1.0
> {code}
> with includes {{zip,jar}} and excludes {{{}war{}}}, I will get the following:
> {code:java}
> com.example:dependency-c:zip:1.0
> com.example:dependency-a:jar:1.0
> {code}
> where dependencies are ordered by their type according to the the includes. I would expect that the filter retains the original order of dependencies, irrespective of the order of includes, i.e.
> {code:java}
> com.example:dependency-a:jar:1.0
> com.example:dependency-c:zip:1.0
> {code}
> This is caused by an invalid order of loops in {{{}org.apache.maven.shared.artifact.filter.collection.AbstractArtifactFeatureFilter#filterIncludes{}}}, where includes are traversed first instead of artifacts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)