ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: dynamically modifying dependency versions during resolve
Date Tue, 08 Jul 2008 09:08:50 GMT
I catch up with this thread a little bit late, but I think I understand both
points of view. Since Ivy philosophy is flexibility, I think Ivy should
support both. Hence I've created an issue about improving Ivy to support
this as a new feature:

The idea is to set an attribute on the resolver which should override (or
force) whatever is requested.

Something like:
            <filesystem name="local" *force="true"*>


On Fri, Jun 27, 2008 at 3:42 PM, Shawn Castrianni <> wrote:

> Exactly.  I agree with everything you said.
> I am using a post beta1 feature called resolveMode="dynamic".  However,
> currently for it to work smoothly, you have to turn on
> defaultResolveMode="dynamic" which essentially makes all modules get
> resolved with the latest rule regardless of any specific revision numbers a
> normal resolve would find.  With this, a chained resolver with a local
> filesystem resolver first in the chain with returnFirst="true" works nicely.
>  This works but isn't ideal because defaultResolveMode="dynamic" affects all
> modules.  Ideally, I only want the modules that have a locally published
> module to be dynamic, but all others to perform a normal "default" resolve.
>  That would require me to, at ANT buildtime, discover what modules existed
> in the locally published repo and somehow turn on only those modules to be
> resolveMode="dynamic".
> ---
> Shawn Castrianni
> -----Original Message-----
> From: Ernest Pasour []
> Sent: Friday, June 27, 2008 8:02 AM
> To:
> Subject: RE: dynamically modifying dependency versions during resolve
> I think part of the disconnect here is that I (I can't speak for Shawn) am
> approaching this from a "good enough" standpoint.  I am only concerned about
> enabling local builds/runs that developers can do; I do not want to affect
> the official (nightly) company builds, which have to be correct.  So
> developers->good enough, nightly builds->correct.
> There are two large classes of code changes that "good enough" can easily
> support.
> 1. behavioral changes (no api changes)
> 2. api additions
> It is up to developers to know when there is a breaking api change that
> will force them to build the entire affected cloud of modules.  It is common
> for developers to use even incompatible modules for testing due to their
> knowledge of the actual runtime paths needed.  The build-time
> incompatibilities don't matter as long as the developer can get the jars
> with changed API.  The alternative at our site is unpalatable: Dev1 builds a
> new jar and asks Dev2 to try it out, but doing so requires republishing 200
> jars.  Most developers will push and pray.
> What I want:
> 1. A way to tweak the resolver settings or provide a new resolver (I have
> some flexibility here to tweak the settings file) so that versions of
> modules in the dev area always get used.  Note that this does not imply
> "latest".  In my environment, it is entirely possible for the version of my
> locally-built module to be "latest in the system", but lose that title when
> the nightly build runs subsequently.  So I really want an "override" to the
> Ivy resolve.
> 2. I don't want to modify the ivy.xml file, due to the risk of these
> development-time changes getting pushed.
>        2a. I want to support collaborations between multiple developers in
> a test repository.  There would have to be lots of modifications to the
> ivy.xml files in this case.
> I am stuck on Ivy2.0Beta1 for the foreseeable future.
> As I mentioned in my original post, I have partially gotten this to work by
> creating my own resolver, but I haven't figured out where to insert code to
> change the version number sought.  So, the code comes in looking for C1, and
> I modify the ModuledRevisionId on the stack to point to C2.  It appears that
> the code then correctly finds my locally-built module.  However, the
> directory that gets created has the revision corresponding to C1.  So I
> think I am inserting myself into the resolve process too late.
> Any hints on what kind of hook (resolver, conflict manager, etc.) I can use
> to dynamically tweak explicit published revisions?
> Thanks,
> Ernest
> -----Original Message-----
> From: Niklas Matthies []
> Sent: Thursday, June 26, 2008 11:03 PM
> To:
> Subject: Re: dynamically modifying dependency versions during resolve
> On Thu 2008-06-26 at 20:48h, Shawn Castrianni wrote on ivy-user:
> > I guess I will give up after this email because I am not getting my point
> across as to why I need this.  I will answer one of your questions and leave
> it at that.
> >
> > > What I wonder here is: After you've tested C2 with A and published
> > > it to the public repository, how can that testing be put to use?
> > > Builds of A or dependencies on A will still get the old C1, *unless*
> > > a dependency on C2 is specified somewhere by some module. Then why
> > > should the testing be able to do without specifiying that dependency?
> >
> > If C contains interfaces and A contains implementations of those
> > interfaces, I want to make sure my interface changes in C do not break
> > the build of A before I checkin my changes to C.
> Well, a build of A will only get these interface changes if the dependency
> of B to C changes, right? Which means that this won't happen unless and
> until there's a new revision of B. If there is to be a new revision of B now
> depending on the new C, the new C will also have to be tested with the new
> B. So why can't the test of A wait until that new revision of B, without
> which there can't be any build of A that would break due to the new C?
> And given a new revision of B, A has to be tested against that anyway, so
> you can simply test against C at the same time in one go.
> Depending on whether the maintainer of B and C is the same or not, we
> handle such cases by testing B with C and then A with B and C by either
> publishing B and C locally (same maintainer) or publishing in the shared
> repository but with status=testing (different maintainers). An alternative
> to the latter would be to publish to a shared "testing" repository which is
> chained between the local and the regular shared repository.
> [...]
> > I can't believe Ernest Pasour and myself are the only ones needing this
> behavior.
> If I understand you correctly, you would want the newest revision of
> *any* transitive dependency. This is something I certainly wouldn't want,
> as bumping up all dependencies throughout the dependency tree can have all
> sorts of effects and cause breakage for reasons totally unrelated to what
> actually needs to be tested. I would only want to update the dependencies
> for what I plan to transitively depend on (C, in the above case), and that
> means specifying somewhere in test build environment of A that a newer
> revision of (specifically) C should be used. And this is nothing different
> than a build dependency of A on C.
> One can use a dedicated "testbuild" conf to play safe.
> -- 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.

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message