You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2011/08/06 19:02:27 UTC
[jira] [Created] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
-------------------------------------------------------------------------------------------------------
Key: FELIX-3070
URL: https://issues.apache.org/jira/browse/FELIX-3070
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.7.2
Reporter: Chetan Mehrotra
Priority: Minor
Here is the scenario. I have two modules
* ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
** scr-bug:moduleA:jar:1.0.0-SNAPSHOT
** scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
* Module B - Has dependency on both artifacts.
Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
Now when ModuleB has dependencies defined in order
# scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
# scr-bug:moduleA:jar:1.0.0-SNAPSHOT
Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
I have also attached the debug log.
If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
{noformat}
[DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
[DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
[DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
[DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
{noformat}
Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated FELIX-3070:
-----------------------------------
Attachment: scr-bug-log.txt
scr-log.txt
SCR Plugin output logs depending on the scenario
> SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3070
> URL: https://issues.apache.org/jira/browse/FELIX-3070
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.7.2
> Reporter: Chetan Mehrotra
> Priority: Minor
> Attachments: scr-bug-log.txt, scr-bug.zip, scr-log.txt
>
>
> Here is the scenario. I have two modules
> - ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> - Module B - Has dependency on both artifacts.
> Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
> Now when ModuleB has dependencies defined in order
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
> I have also attached the debug log.
> If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
> [DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> [DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated FELIX-3070:
-----------------------------------
Attachment: scr-bug.zip
Maven project to demonstrate the issue
> SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3070
> URL: https://issues.apache.org/jira/browse/FELIX-3070
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.7.2
> Reporter: Chetan Mehrotra
> Priority: Minor
> Attachments: scr-bug-log.txt, scr-bug.zip, scr-log.txt
>
>
> Here is the scenario. I have two modules
> - ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> - Module B - Has dependency on both artifacts.
> Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
> Now when ModuleB has dependencies defined in order
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
> I have also attached the debug log.
> If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
> [DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> [DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
Posted by "Carsten Ziegeler (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler resolved FELIX-3070.
-------------------------------------
Resolution: Fixed
Fix Version/s: maven-scr-plugin-1.7.4
Thanks for reporting and especially for the test case, Chetan!
I've fixed this in revision 1176365
The code was a little bit strange and I guess we had a wrong idea of the maven api at the time of writing. :)
> SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3070
> URL: https://issues.apache.org/jira/browse/FELIX-3070
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.7.2
> Reporter: Chetan Mehrotra
> Assignee: Carsten Ziegeler
> Priority: Minor
> Fix For: maven-scr-plugin-1.7.4
>
> Attachments: scr-bug-log.txt, scr-bug.zip, scr-log.txt
>
>
> Here is the scenario. I have two modules
> - ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> - Module B - Has dependency on both artifacts.
> Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
> Now when ModuleB has dependencies defined in order
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
> I have also attached the debug log.
> If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
> [DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> [DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
Posted by "Carsten Ziegeler (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler closed FELIX-3070.
-----------------------------------
> SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3070
> URL: https://issues.apache.org/jira/browse/FELIX-3070
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.7.2
> Reporter: Chetan Mehrotra
> Assignee: Carsten Ziegeler
> Priority: Minor
> Fix For: maven-scr-plugin-1.7.4
>
> Attachments: scr-bug-log.txt, scr-bug.zip, scr-log.txt
>
>
> Here is the scenario. I have two modules
> - ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> - Module B - Has dependency on both artifacts.
> Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
> Now when ModuleB has dependencies defined in order
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
> I have also attached the debug log.
> If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
> [DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> [DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
Posted by "Chetan Mehrotra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chetan Mehrotra updated FELIX-3070:
-----------------------------------
Description:
Here is the scenario. I have two modules
- ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
-- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
-- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
- Module B - Has dependency on both artifacts.
Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
Now when ModuleB has dependencies defined in order
-- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
-- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
I have also attached the debug log.
If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
[DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
[DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
[DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
[DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
was:
Here is the scenario. I have two modules
* ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
** scr-bug:moduleA:jar:1.0.0-SNAPSHOT
** scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
* Module B - Has dependency on both artifacts.
Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
Now when ModuleB has dependencies defined in order
# scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
# scr-bug:moduleA:jar:1.0.0-SNAPSHOT
Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
I have also attached the debug log.
If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
{noformat}
[DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
[DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
[DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
[DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
{noformat}
Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
> SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3070
> URL: https://issues.apache.org/jira/browse/FELIX-3070
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.7.2
> Reporter: Chetan Mehrotra
> Priority: Minor
>
> Here is the scenario. I have two modules
> - ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> - Module B - Has dependency on both artifacts.
> Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
> Now when ModuleB has dependencies defined in order
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
> I have also attached the debug log.
> If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
> [DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> [DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (FELIX-3070) SCR Plugin and dependencies with
classifier cause issue depending on the order of dependency in pom.xml
Posted by "Carsten Ziegeler (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler reassigned FELIX-3070:
---------------------------------------
Assignee: Carsten Ziegeler
> SCR Plugin and dependencies with classifier cause issue depending on the order of dependency in pom.xml
> -------------------------------------------------------------------------------------------------------
>
> Key: FELIX-3070
> URL: https://issues.apache.org/jira/browse/FELIX-3070
> Project: Felix
> Issue Type: Bug
> Components: Maven SCR Plugin
> Affects Versions: maven-scr-plugin-1.7.2
> Reporter: Chetan Mehrotra
> Assignee: Carsten Ziegeler
> Priority: Minor
> Attachments: scr-bug-log.txt, scr-bug.zip, scr-log.txt
>
>
> Here is the scenario. I have two modules
> - ModuleA - It generates two artifact. One the main artifact and other a client artifact which has classifier set to 'client' i.e.
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> - Module B - Has dependency on both artifacts.
> Module A has a abstract service class which has Component 's componentAbstract set to true. This class has a service reference entry i.e. a variable with @Reference marked. Module B has a ExampleService which extends the AbstractService and it has been marked aith Component annotation
> Now when ModuleB has dependencies defined in order
> -- scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT
> -- scr-bug:moduleA:jar:1.0.0-SNAPSHOT
> Then SCR Plugin is able to locate the abstract component configuration and adds dependency on the required service (referred in AbstractService). However if the order is changed (i.e. classifier entry comes later) then SCR plguin ignores the config.
> I have also attached the debug log.
> If you see scr-bug-log.txt (when dependency entry with classifier comes later) then it has entries which indicates that dependency without classifier has been ignored
> [DEBUG] Checking artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Resolving artifact org.apache.felix:org.apache.felix.scr.annotations:jar:1.6.0:provided
> [DEBUG] Checking artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> [DEBUG] Resolving artifact scr-bug:moduleA:jar:client:1.0.0-SNAPSHOT:compile
> Seeing the code of MavenJavaClassDescriptorManager then it uses MavenProject.getArtifactMap() in the getDependencies method. It internally uses org.apache.maven.artifact.ArtifactUtils.artifactMapByVersionlessId [1]. This method only uses artifactId and groupId to create the map key and does not take into account the classifier. So the getDependencies logic should use some other method to obtain the depndencies
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira