[ 
https://issues.apache.org/jira/browse/IVY-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982413#comment-15982413
 ] 

jaikiran pai commented on IVY-1485:
-----------------------------------

[~chinhodado], Ivy project is indeed dead for all practical purposes. During 
the past year or so I have tried asking more than once on the Ivy dev mailing 
list to see if there's any possibility of reviving it. I have even volunteered 
to help in some ways to revive it. However, all I hear is the usual replies 
like "it's open source, feel free to contribute" and some promises that there 
is life in this project. In reality though, there's been practically zero 
development in this project for the past few years now and I personally don't 
see any change in it, in near future.

We do use Ivy internally for some of our projects, but it's become hard to 
stick around with it any more and we do have plans to our product to a 
different build system soon.


> Incorrect revision of dependencies put in to delivered Ivy files
> ----------------------------------------------------------------
>
>                 Key: IVY-1485
>                 URL: https://issues.apache.org/jira/browse/IVY-1485
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.3.0, 2.4.0-RC1
>            Reporter: Perrin Morrow
>            Priority: Critical
>         Attachments: 0001-Add-test-cases-for-IVY-1485.patch, 
> 0002-Ensure-dependency-is-applicable-to-all-confs-of-matc.patch, 
> ivy-1485-test-cases.patch
>
>
> Ivy deliver incorrectly replaces top-level dependency revision with one from 
> a transitive dependency in a different conf.
> When writing the resolved Ivy properties into the cache, the Ivy 
> ResolveEngine does not take into account the top-level confs. If it finds the 
> same dependency on any transitive path it will prefer the resolved revision 
> of the transitive dependency over that of the top-level dependency even when 
> that transitive dependency is being resolved into a completely different 
> top-level conf. This results in a delivered Ivy file, that when resolved 
> again will pull in the wrong version of that top-level dependency.
> Consider the following Ivy dependency chain:
> {noformat}
> top-level
>   [conf1]
>     - modA#1
>   [conf2]
>     - modB#1
>       - modA#2
> {noformat}
> Ivy resolve and retrieve will pull modA#1 into conf1 and modA#2 into conf2, 
> as expected.
> Ivy deliver, however, will replace modA#1 with modA#2 in the delivered ivy 
> descriptor. When that delivered ivy file is resolved again (by some other 
> module depending on it) it will pull in modA#2 into both conf1 and conf2.
> This appears to be a regression in Ivy 2.3.0.  It did not happen with Ivy 
> 2.2.0.  (Maybe related to IVY-1300?)
> We have written some test cases that demonstrate the problem (a diff against 
> the Git repository master) which I will attach.
> We're also working on a patch to fix this but so far it has proved elusive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to