ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <Shawn.Castria...@halliburton.com>
Subject RE: dynamically modifying dependency versions during resolve
Date Thu, 26 Jun 2008 22:18:15 GMT
Right, if we start requiring developers to change their ivy.xml files to get their job done,
they might accidentally check it in to source repository.  As the CM guy, I want to be in
charge of ivy.xml and settings.xml files exclusively and have the ant build script handle
this stuff automatically.

---
Shawn Castrianni


-----Original Message-----
From: Jim Adams [mailto:Jim.Adams@sas.com]
Sent: Thursday, June 26, 2008 5:13 PM
To: ivy-user@ant.apache.org
Subject: RE: dynamically modifying dependency versions during resolve

I think one of the problems is that you don't want that dependency to "leak" into your code.
You certainly don't want to push your ivy file out with that change. Imagine an organization
with thousands of developers and people started to push out "bad" dependencies like that.
I shudder....

> -----Original Message-----
> From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
> Sent: Thursday, June 26, 2008 6:09 PM
> To: ivy-user@ant.apache.org
> Subject: Re: dynamically modifying dependency versions during resolve
>
> On Thu 2008-06-26 at 16:44h, Shawn Castrianni wrote on ivy-user:
> :
> > 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.
>
> Yes, I remember. Your use case was that there are dependencies A->B->C
> and the developer locally publishes an update to C, and then wants to
> test it with his version of A, but resolving for A doesn't pick up the
> newer revision of C because the publically published version of B
> depends on the older (publically published) version of C.
>
> Personally I think it's fine in that case to either temporarily add a
> dependency A->C or locally publish a version of B with an updated
> dependency B->C. The normal case for me is that the changes in A
> depend on the changes in C, and hence one of these dependency updates
> will become necessary anyway.
>
> (Yeah, "publically published" sounds stupid.)
>
> -- 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.

Mime
View raw message