[
http://jira.codehaus.org/browse/MNG-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3408:
------------------------------
Description:
This problem is preventing for instance parallel builds to run in a continuous
server, without broken builds being falsely reported from time to time.
Ex:
- Project B is depending on artifacts from Project A.
- Builds for Project A and Project B are both triggered at the same time.
- The build of project A finishes earlier, so that Project A deploys its
artifacts while Project B is still building (replacing the previous artifacts).
What can happen is that the build of Project B suddenly breaks, because it
needs an artifact of Project A for which it already resolved the dependency,
but yet of a different type. Maven is writing the local metadata file when
resolving the pair groupId:artifactId of the first type, and is reading the
same metadata file when resolving the same pair of the second type (which may
come later in the build).
Actually I think that groupId:artifactId:type should be considered for the
uniqueness of artifacts instead of groupId:artifactId, and this information be
contained in the local metadata files.
was:
This problem is preventing for instance parallel builds to run in a continuous
server, without broken builds being falsely reported from time to time.
Ex:
- Project B is depending on artifacts from Project A.
- Builds for Project A and Project B are both triggered at the same time.
- The build of project A finishes earlier, so that Project A deploys its
artifacts while Project B is still building (replacing the previous artifacts).
What can happen is that the build of Project B suddenly breaks, because it
needs an artifact of Project A for which it already resolved the dependency,
but yet of a different type. Maven is writing the local metadata file when
resolving the pair groupId:artifactId of the first type, and is reading the
same metadata file when resolving the same pair of the second type (which may
come later in the build).
Actually I think that groupId:artifactId:type should be considered for the
uniqueness of artifacts instead of groupId:artifactId, and this information be
contained in the local metadata files.
Fix Version/s: 2.1
> Artifacts with the same pair groupId:artifactId but different type are not
> resolved independently
> -------------------------------------------------------------------------------------------------
>
> Key: MNG-3408
> URL: http://jira.codehaus.org/browse/MNG-3408
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 2.0.8
> Reporter: Nicolas Malassigné
> Fix For: 2.1
>
>
> This problem is preventing for instance parallel builds to run in a
> continuous server, without broken builds being falsely reported from time to
> time.
> Ex:
> - Project B is depending on artifacts from Project A.
> - Builds for Project A and Project B are both triggered at the same time.
> - The build of project A finishes earlier, so that Project A deploys its
> artifacts while Project B is still building (replacing the previous
> artifacts).
> What can happen is that the build of Project B suddenly breaks, because it
> needs an artifact of Project A for which it already resolved the dependency,
> but yet of a different type. Maven is writing the local metadata file when
> resolving the pair groupId:artifactId of the first type, and is reading the
> same metadata file when resolving the same pair of the second type (which may
> come later in the build).
> Actually I think that groupId:artifactId:type should be considered for the
> uniqueness of artifacts instead of groupId:artifactId, and this information
> be contained in the local metadata files.
--
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
