You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Chris Tucker (JIRA)" <ji...@codehaus.org> on 2007/03/14 21:34:33 UTC
[jira] Created: (MPEAR-48) Ear plugin fails to resolve artifact
with null classifier when equivalent, classified artifact exists
Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
-----------------------------------------------------------------------------------------------------
Key: MPEAR-48
URL: http://jira.codehaus.org/browse/MPEAR-48
Project: maven-ear-plugin
Issue Type: Bug
Reporter: Chris Tucker
When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEAR-59) Unable to customize the main artifact when
it is used together with an attached artifact
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll closed MEAR-59.
-------------------------------
Resolution: Fixed
I didn''t apply your patch, we need to have an explicit config for the main artifact.
By default <classifier>none</classifier> refers to the main artifact. This can be changed using the mainArtifactId parameter of the EAR plugin.
> Unable to customize the main artifact when it is used together with an attached artifact
> ----------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Assigned To: Stephane Nicoll
> Fix For: 2.3.1
>
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPEAR-48) Ear plugin fails to resolve artifact
with null classifier when equivalent, classified artifact exists
Posted by "Chris Tucker (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MPEAR-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Tucker updated MPEAR-48:
------------------------------
Attachment: MPEAR-48-maven-ear-plugin.patch
> Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
> -----------------------------------------------------------------------------------------------------
>
> Key: MPEAR-48
> URL: http://jira.codehaus.org/browse/MPEAR-48
> Project: maven-ear-plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MEAR-59) Ear plugin fails to resolve artifact with
null classifier when equivalent, classified artifact exists
Posted by "Lukas Theussl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukas Theussl moved MPEAR-48 to MEAR-59:
----------------------------------------
Workflow: Maven New (was: jira)
Key: MEAR-59 (was: MPEAR-48)
Project: Maven 2.x Ear Plugin (was: maven-ear-plugin)
> Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
> -----------------------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-59) Ear plugin fails to resolve artifact
with null classifier when equivalent, classified artifact exists
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90948 ]
Stephane Nicoll commented on MEAR-59:
-------------------------------------
However, you will have to specify <classifier></classifer> explicitely. If they are two candidates, you have to explicitly state that you want the main artifact (still need to be validated though)
> Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
> -----------------------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Assigned To: Stephane Nicoll
> Fix For: 2.3.1
>
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-59) Ear plugin fails to resolve artifact
with null classifier when equivalent, classified artifact exists
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90966 ]
Stephane Nicoll commented on MEAR-59:
-------------------------------------
mmm specifying an empty classifier like this <classifier></classifier> won't work since plexus with inject a 'null' classifier. We need to specify we want the main artifact...
> Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
> -----------------------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Assigned To: Stephane Nicoll
> Fix For: 2.3.1
>
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-59) Ear plugin fails to resolve artifact
with null classifier when equivalent, classified artifact exists
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90341 ]
Stephane Nicoll commented on MEAR-59:
-------------------------------------
I don't follow. Could you please add a sample project that at least shows the dependencies and your configuration. If there is more than one artifact with the same groupId/artifactId/type, you *must* specify a classifier.
> Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
> -----------------------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Assigned To: Stephane Nicoll
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-59) Ear plugin fails to resolve artifact with
null classifier when equivalent, classified artifact exists
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll updated MEAR-59:
--------------------------------
Fix Version/s: 2.3.1
OK. I have reproduced the issue.
> Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
> -----------------------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Assigned To: Stephane Nicoll
> Fix For: 2.3.1
>
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-59) Unable to customize the main artifact
when it is used together with an attached artifact
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephane Nicoll updated MEAR-59:
--------------------------------
Summary: Unable to customize the main artifact when it is used together with an attached artifact (was: Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists)
> Unable to customize the main artifact when it is used together with an attached artifact
> ----------------------------------------------------------------------------------------
>
> Key: MEAR-59
> URL: http://jira.codehaus.org/browse/MEAR-59
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
> Reporter: Chris Tucker
> Assigned To: Stephane Nicoll
> Fix For: 2.3.1
>
> Attachments: MPEAR-48-maven-ear-plugin.patch
>
>
> When resolving ear modules the AbstractEarModule.java class requests a unique artifact from the artifact repository using getUniqueArtifact(groupId, artifactId, type, classifier). In the case where the classifier is null getUniqueArtifact will attempt to find an artifact without considering the classifier -- it will match *any* artifact with the same groupId, artifactId, and type, regardless of whether the classifier matches (is null). Currently the logic in AbstractEarModule does not handle the case where the classifier is null: if there is one artifact without a classifier (the one we're looking for) and another with a classifier (e.g. a clover jar) the ear module will throw an exception at line 104 stating that a classifier is required. This means that any build that builds, for example, an instrumented jar, will fail to construct an ear.
> This is fixed in the attached patch by explicitly iterating the set of artifacts that matches a call to getArtifacts() on the artifact repository with just the group, artifact, and type. Ideally this patch would instead be made to ArtifactRepository itself to include a search that explicitly matches null classifiers.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira