You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Maarten Coene (JIRA)" <ji...@apache.org> on 2009/07/02 00:50:47 UTC

[jira] Updated: (IVY-1085) Retrieve ant task doesn't support dynamic resolve mode

     [ https://issues.apache.org/jira/browse/IVY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maarten Coene updated IVY-1085:
-------------------------------

    Affects Version/s:     (was: 2.1.0)
        Fix Version/s: 2.1.0-RC2
             Assignee: Maarten Coene
           Issue Type: Improvement  (was: Bug)
              Summary: Retrieve ant task doesn't support dynamic resolve mode  (was: Retrieve ant task doesn't respect dynamic revisions for transitive dependencies)

> Retrieve ant task doesn't support dynamic resolve mode
> ------------------------------------------------------
>
>                 Key: IVY-1085
>                 URL: https://issues.apache.org/jira/browse/IVY-1085
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Ant
>    Affects Versions: 2.0.x, trunk
>            Reporter: Jarosław Wypychowski
>            Assignee: Maarten Coene
>             Fix For: 2.1.0-RC2
>
>
> let's have modules A, B and C.  A depends on B which depends on C.
> I have following versions released : 
>  - A - none, depends on B : 0.0.+
>  - B - 0.0.1 , depends on C : 0.0.+, released with C rev=0.0.1,
>  - C - 0.0.1 and 0.0.2
> In order to always use freshest released version matching constraints I tried to use resolveMode="dynamic" in resolve task. This worked for resolve (report shows correct dependency choosen (C:0.0.2). However retrieve happily ignores it and downloads 0.0.1. I'm resolving with resolveId and retrieving with the same resolveId.
> I tracked this a little bit.
> Inside IvyPostResolveTask there is prepareAndCheck method. It does some magic which gets down to that ivy in most scenarios (when retrieval is not inline for known module and organisation) does a second resolve inside retrieve to get configurations for retrieval. This is done in ensureResolve method:
>  {code:java}
>      protected void ensureResolved(IvySettings settings) {
>         String requestedConfigs = getProperty(getConf(), settings, "ivy.resolved.configurations");
>             
>         String[] confs = null;
>         if (getResolveId() != null) {
>             confs = getConfsToResolve(getResolveId(), requestedConfigs);
>         } else {
>             confs = getConfsToResolve(getOrganisation(), getModule(), requestedConfigs, false);
>         }
>             
>         if (confs.length > 0) {
>             IvyResolve resolve = createResolve(isHaltonfailure(), isUseOrigin());
>             resolve.setFile(getFile());
>             resolve.setTransitive(isTransitive());
>             resolve.setConf(StringUtils.join(confs, ", "));
>             resolve.setResolveId(getResolveId());
>             resolve.execute();
>         }
>     }
> {code}
> First - could someone please rationalise this resolve inside retrieve ?  
> Second - this resolve happily ignores whatever resolveMode I did set previously. 
> The workaround I did was to extend IvyPostResolveTask with resolveMode parameter and put it explicitly in to the ant config, but maybe there is a better solution ? 
> If the above is accepted I can produce a patch against trunk and post it here. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.