ant-ivy-user mailing list archives

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


-----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

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