ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ernest Pasour (JIRA)" <>
Subject [jira] Commented: (IVY-857) Better support for local builds
Date Tue, 08 Jul 2008 11:28:31 GMT


Ernest Pasour commented on IVY-857:

Sounds great!  I believe the semantics you have listed here are what I would want, but I'll
make a couple of things explicit just in case. 

1. I expect that published dependency revisions will be honored for every item that is not
found by a resolver with "force" turned on.  So I expect that published dependency revisions
for "A" will not be lost just because it is inside a resolver with "force" or that the published
dependency revs of "C" will be lost just because it was resolved via the "force" option.

2. I would like this to support multiple resolvers with the "force" option.  I don't know
of any reason this would be a problem, but I just don't want the possibility precluded.

3. I want the resolver with the "force" option to not have to be the first resolver(s) in
the lookup chain.  My current chain looks like the following (all with returnFirst=true):

 a. local developer playpen  
 b. group playpens (this is where I would put the force option, since I want multiple developers
to be able to contribute to this area)
 c. nightly build

So the idea is that a developer can build a module in his local playpen, and that module always
takes precedence.  

I hope I haven't confused the issue more, and thanks for your attention to this.

> Better support for local builds
> -------------------------------
>                 Key: IVY-857
>                 URL:
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Xavier Hanin
>            Assignee: Xavier Hanin
> Currently Ivy suggests to use a local filesystem resolver in a chain with returnFirst="true"
to support local builds. It works well as long as you have control over the dependency revision
requested, and can hence ask for a latest.integration version. But in some cases it would
be nice to also override a transitive dependency, where do not control the requested revision.
> Eg:
> #A -> #B;1.0 -> #C;1.0
> A developer work on #A and #C, and want to use a local build for #C. But this requires
a local publication of #B too, just too override the dependency on #C. It would be better
to have a resolver able to force the returned module for the dependency on #C to a locally
published module, whatever the requested revision is.

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

View raw message