ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Adams <>
Subject RE: dynamically modifying dependency versions during resolve
Date Thu, 26 Jun 2008 21:59:36 GMT
In a system where that are many jars and many tendrils it becomes very difficult to work on
a small number of those jars. If I have 2 jars that I am working on but the chain between
them has more than one link then I am obliged to build and publish all the links in between
in order to see my changes. Solving Ernest's and Shawn's problem would solve this as well.
I realize that this is not "correct" but it is a valid use case for local development. When
you release you have to use the full transitive closure.

> -----Original Message-----
> From: Shawn Castrianni []
> Sent: Thursday, June 26, 2008 5:45 PM
> To:
> Subject: RE: dynamically modifying dependency versions during resolve
> My guess is he wants what I want which I described in a previous mailing list post. 
I would like to be able to
> setup a local repository that developers can locally publish to that takes precedence
over any published module
> in the real repository.  That way a developer that is working on multiple modules at
one time, can build the
> first one and publish it locally as version "LOCAL" or something.  Then he can switch
to a higher level module
> and when resolving, it will pick up the locally published module first instead of the
one on the repository that
> is specified in the transitive ivy.xml files.  This allows developers to test source
code across multiple
> modules before having to checkin anything and wait for an official build from some automated
> Now you might think, this is already supported with a chained resolver returnFirst="true".
 That would be true
> except for the revision number.  The locally published module may not have the same revision
number that a
> transitive resolve would find.  Therefore, it would skip the locally published module
since "LOCAL" isn't what
> it is looking for.  I think we both want the locally published module to take precedence
regardless of what the
> revision is.
> Currently the only way to do this is to turn on resolveMode="dynamic" for that module.
 But the problem with
> this is I don't want resolveMode="dynamic" turned on ALL the time.  I just want it on
when there is a localy
> published module.  So I need to be able to programmatically know at runtime whether to
> resolveMode="dynamic" based on whether a locally published module exists.
> I guess to answer your question as to why is what I said before.  To allow a developer
to test his source code
> changes in one module against his source code changes in another module all locally without
having to checkin
> anything to the source code repository and wait for an official build.
> ---
> Shawn Castrianni
> -----Original Message-----
> From: Niklas Matthies []
> Sent: Thursday, June 26, 2008 4:29 PM
> To:
> Subject: Re: dynamically modifying dependency versions during resolve
> On Thu 2008-06-26 at 17:18h, Ernest Pasour wrote on ivy-user:
> > I am trying to modify an ivy system to have special resolve handling
> > at development time.  My goal is to add another resolver (R1) before
> > the published repository that will *always* find a module if any
> > version of that module exists in R1.
> >
> > Ex. The repository denoted by R1 contains modules E3 and F3
> >     The published repository contains modules A1 B1 C1 D1 E1 F1 G1
> > G1 depends upon F1 explicitly in its Ivy file.
> >
> > So when a build happens and G1 is resolved, I want R1 to get in the
> > way and say, "No, I don't have F1, but I do have F3, so that's what
> > I'll return".
> >
> > What is the best way (if any) to accomplish this?
> Maybe you could explain why you want this behavior.
> There may be other, simpler ways to achieve your actual goal.
> -- Niklas Matthies
> ----------------------------------------------------------------------
> This e-mail, including any attached files, may contain confidential and privileged information
for the sole use
> of the intended recipient.  Any review, use, distribution, or disclosure by others is
strictly prohibited.  If
> you are not the intended recipient (or authorized to receive information for the intended
recipient), please
> contact the sender by reply e-mail and delete all copies of this message.

View raw message