ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin (JIRA)" <>
Subject [jira] Resolved: (IVY-740) Add a new resolve mode (optionally per module) to utilize new "original constraint rule" metadata in IVY-739
Date Sun, 02 Mar 2008 08:58:50 GMT


Xavier Hanin resolved IVY-740.

       Resolution: Fixed
    Fix Version/s: 2.0-RC1

I've implemented this new feature, we now have two resolve modes:
- 'default', which corresponds to the classic resolve mode, and behave as usual
- 'dynamic', which uses revContstraint attributes instead of rev when analysing dependency

To implement this, I've concentrated the responsibility to know which revision is required
by a dependency descriptor in ResolveEngine#getRequestedDependencyRevisionId(DependencyDescriptor,
ResolveOptions) . This should also ease the implementation of IVY-753 (we may have to change
the signature of the method though, to get more context).

> Add a new resolve mode (optionally per module) to utilize new "original constraint rule"
metadata in IVY-739
> ------------------------------------------------------------------------------------------------------------
>                 Key: IVY-740
>                 URL:
>             Project: Ivy
>          Issue Type: New Feature
>            Reporter: Shawn Castrianni
>            Assignee: Xavier Hanin
>             Fix For: 2.0-RC1
> After IVY-739 is resolved, ivy will have new metadata that keeps the "original constraint
rule" metadata in published/delivered ivy files.  Therefore, during a resolve, it would be
nice to be able to use the original constraint rule instead of the specific revision it was
published with by toggling on a new resolve mode.  Maybe this mode is toggled on via a new
attribute on the resolve task, not sure.  But what is important is that this new resolve mode
can be toggled on or off on a per module basis by a new attribute, perhaps "resolveMode" or
"mode", on the module tag in the settings file.  This would allow a specific module to always
be resolved to the lastest version in the repo regardless of what was used to build the parent
module that is referencing it.

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

View raw message