[
https://issues.apache.org/jira/browse/IVY-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Novak updated IVY-1345:
-----------------------------
Description:
Modules A, B, C:
Module B and C extend A, A not having any revision specified.
Module C depends on B using a configuration inherited from A, B will be
published as 1.0, C depends on 1.0
In this configuration, it might happen that the ivy:buildlist does not order B
and C properly, try with the attached project, run "ant _sort-modules" from
build-essentials directory.
For the first time, it sorts correctly, but the module A appears in the local
cache. When you run the ant _sort-modules for the second time, the order of A
and B is reversed.
What might be happening is that the module A is put to the local cache, but
with revision="working@module-inheritance-repository". Module B inherits this
revision, and since Module C specifies exact revision "1.0", these two do not
match and the dependency is not taken into account while ordering the modules.
I think that the revisions of the parent modules should be ignored.
Also, if you specify exact revision for A, e.g. 2.0, which won't match with the
dependency specified in C ivy.xml (1.0), there is the same behavior. Only if A
would specify 1.0, which matches the dependency, sort order is correct.
was:
Modules A, B, C:
Module B and C extend A using location attribute in the <info><extends
location=""/></info> tag.
Module C depends on B using a configuration inherited from A.
No module has the revision specified.
In this configuration, it might happen that the ivy:buildlist does not order B
and C properly, try with the attached project, run "ant _sort-modules" from
build-essentials directory.
For the first time, it sorts correctly, but the module A appears in the local
cache. When you run the ant _sort-modules for the second time, the order of A
and B is reversed.
What might be happening is that the module A is put to the local cache, but
with revision="working@module-inheritance-repository". Module B inherits this
revision, and since Module C specifies exact revision "1.0", these two does not
match and the dependency is not taken into account while ordering the modules.
I think that the revisions of the parent modules should be ignored.
Summary: ivy:buildlist does not order properly modules that extend
module with revision not matching dependencies (was: ivy:buildlist does not
order properly modules that extend using location attribute)
Correcting the bug description, this is not related to the "location" attribute
usage, but only the revision numbers.
> ivy:buildlist does not order properly modules that extend module with
> revision not matching dependencies
> --------------------------------------------------------------------------------------------------------
>
> Key: IVY-1345
> URL: https://issues.apache.org/jira/browse/IVY-1345
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.3.0-RC1, trunk
> Environment: Tested with Ant 1.8.2 and 1.8.3
> Reporter: Pavel Novak
> Attachments: ivy_sorting_issue.zip
>
>
> Modules A, B, C:
> Module B and C extend A, A not having any revision specified.
> Module C depends on B using a configuration inherited from A, B will be
> published as 1.0, C depends on 1.0
> In this configuration, it might happen that the ivy:buildlist does not order
> B and C properly, try with the attached project, run "ant _sort-modules" from
> build-essentials directory.
> For the first time, it sorts correctly, but the module A appears in the local
> cache. When you run the ant _sort-modules for the second time, the order of A
> and B is reversed.
> What might be happening is that the module A is put to the local cache, but
> with revision="working@module-inheritance-repository". Module B inherits this
> revision, and since Module C specifies exact revision "1.0", these two do not
> match and the dependency is not taken into account while ordering the
> modules. I think that the revisions of the parent modules should be ignored.
> Also, if you specify exact revision for A, e.g. 2.0, which won't match with
> the dependency specified in C ivy.xml (1.0), there is the same behavior. Only
> if A would specify 1.0, which matches the dependency, sort order is correct.
--
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
