Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: domain of
 Shawn.Castrianni@halliburton.com designates 34.254.16.14 as permitted sender)
From: Shawn Castrianni <Shawn.Castrianni@halliburton.com>
To: "'ivy-user@ant.apache.org'" <ivy-user@ant.apache.org>
Date: Fri, 27 Jun 2008 08:42:47 -0500
Subject: RE: dynamically modifying dependency versions during resolve
Thread-Topic: dynamically modifying dependency versions during resolve
Thread-Index: AcjYAnJpT5ccYLReSU27vwj5NC/PtQATD/BQAAMERLA=
Message-ID: 
 <745B9EDF57802349B13F90E4E0B4B86C3BA402C1F6@HOUEXCH012.corp.halliburton.com>
In-Reply-To: <15412A37E8C9574393B24ADD991FAA760A2646EF0F@MERCMBX14.na.sas.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Exactly.  I agree with everything you said.

I am using a post beta1 feature called resolveMode=3D"dynamic".  However, c=
urrently for it to work smoothly, you have to turn on defaultResolveMode=3D=
"dynamic" which essentially makes all modules get resolved with the latest =
rule regardless of any specific revision numbers a normal resolve would fin=
d.  With this, a chained resolver with a local filesystem resolver first in=
 the chain with returnFirst=3D"true" works nicely.  This works but isn't id=
eal because defaultResolveMode=3D"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 m=
e to, at ANT buildtime, discover what modules existed in the locally publis=
hed repo and somehow turn on only those modules to be resolveMode=3D"dynami=
c".


---
Shawn Castrianni

-----Original Message-----
From: Ernest Pasour [mailto:Ernest.Pasour@sas.com]
Sent: Friday, June 27, 2008 8:02 AM
To: ivy-user@ant.apache.org
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 abou=
t enabling local builds/runs that developers can do; I do not want to affec=
t the official (nightly) company builds, which have to be correct.  So deve=
lopers->good enough, nightly builds->correct.

There are two large classes of code changes that "good enough" can easily s=
upport.
1. behavioral changes (no api changes)
2. api additions

It is up to developers to know when there is a breaking api change that wil=
l force them to build the entire affected cloud of modules.  It is common f=
or developers to use even incompatible modules for testing due to their kno=
wledge of the actual runtime paths needed.  The build-time incompatibilitie=
s 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 dev=
elopers will push and pray.

What I want:
1. A way to tweak the resolver settings or provide a new resolver (I have s=
ome flexibility here to tweak the settings file) so that versions of module=
s 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 nig=
htly build runs subsequently.  So I really want an "override" to the Ivy re=
solve.
2. I don't want to modify the ivy.xml file, due to the risk of these develo=
pment-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 iv=
y.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 t=
o 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 thi=
nk 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 [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 11:03 PM
To: ivy-user@ant.apache.org
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 lea=
ve 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 unt=
il there's a new revision of B. If there is to be a new revision of B now d=
epending 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 whi=
ch 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 y=
ou 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 handl=
e such cases by testing B with C and then A with B and C by either publishi=
ng B and C locally (same maintainer) or publishing in the shared repository=
 but with status=3Dtesting (different maintainers). An alternative to the l=
atter 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 b=
ehavior.

If I understand you correctly, you would want the newest revision of
*any* transitive dependency. This is something I certainly wouldn't want, a=
s bumping up all dependencies throughout the dependency tree can have all s=
orts of effects and cause breakage for reasons totally unrelated to what ac=
tually 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 mea=
ns specifying somewhere in test build environment of A that a newer revisio=
n 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 pri=
vileged information for the sole use of the intended recipient.  Any review=
, use, distribution, or disclosure by others is strictly prohibited.  If yo=
u are not the intended recipient (or authorized to receive information for =
the intended recipient), please contact the sender by reply e-mail and dele=
te all copies of this message.