[
https://issues.apache.org/jira/browse/IVY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611530#action_12611530
]
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: https://issues.apache.org/jira/browse/IVY-857
> 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.
