ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ernest Pasour <>
Subject RE: dynamically modifying dependency versions during resolve
Date Fri, 27 Jun 2008 13:01:51 GMT
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?


-----Original Message-----
From: Niklas Matthies []
Sent: Thursday, June 26, 2008 11:03 PM
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

View raw message