You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Ernest Pasour <Er...@sas.com> on 2008/06/26 23:18:35 UTC
dynamically modifying dependency versions during resolve
I am trying to modify an ivy system to have special resolve handling at development time. My goal is to add another resolver (R1) before the published repository that will *always* find a module if any version of that module exists in R1.
Ex. The repository denoted by R1 contains modules E3 and F3
The published repository contains modules A1 B1 C1 D1 E1 F1 G1
G1 depends upon F1 explicitly in its Ivy file.
So when a build happens and G1 is resolved, I want R1 to get in the way and say, "No, I don't have F1, but I do have F3, so that's what I'll return".
What is the best way (if any) to accomplish this?
I'm experimenting now with overriding the RespositoryResolver. findResourceUsingPattern(...) method to add this special handling. This seems to work for resolve, but the retrieve still pulls down F1. I think this is because the ModuleRevisionId that is passed in still has the version F1, so instead of changing the version to F3, I've just partially fooled ivy into thinking that F1 exists in the F3 location.
Thanks for any suggestions,
Ernest
RE: dynamically modifying dependency versions during resolve
Posted by Jim Adams <Ji...@sas.com>.
In a system where that are many jars and many tendrils it becomes very difficult to work on a small number of those jars. If I have 2 jars that I am working on but the chain between them has more than one link then I am obliged to build and publish all the links in between in order to see my changes. Solving Ernest's and Shawn's problem would solve this as well. I realize that this is not "correct" but it is a valid use case for local development. When you release you have to use the full transitive closure.
> -----Original Message-----
> From: Shawn Castrianni [mailto:Shawn.Castrianni@halliburton.com]
> Sent: Thursday, June 26, 2008 5:45 PM
> To: ivy-user@ant.apache.org
> Subject: RE: dynamically modifying dependency versions during resolve
>
> My guess is he wants what I want which I described in a previous mailing list post. I would like to be able to
> setup a local repository that developers can locally publish to that takes precedence over any published module
> in the real repository. That way a developer that is working on multiple modules at one time, can build the
> first one and publish it locally as version "LOCAL" or something. Then he can switch to a higher level module
> and when resolving, it will pick up the locally published module first instead of the one on the repository that
> is specified in the transitive ivy.xml files. This allows developers to test source code across multiple
> modules before having to checkin anything and wait for an official build from some automated server.
>
> Now you might think, this is already supported with a chained resolver returnFirst="true". That would be true
> except for the revision number. The locally published module may not have the same revision number that a
> transitive resolve would find. Therefore, it would skip the locally published module since "LOCAL" isn't what
> it is looking for. I think we both want the locally published module to take precedence regardless of what the
> revision is.
>
> Currently the only way to do this is to turn on resolveMode="dynamic" for that module. But the problem with
> this is I don't want resolveMode="dynamic" turned on ALL the time. I just want it on when there is a localy
> published module. So I need to be able to programmatically know at runtime whether to have
> resolveMode="dynamic" based on whether a locally published module exists.
>
> 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.
>
> ---
> Shawn Castrianni
>
>
> -----Original Message-----
> From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
> Sent: Thursday, June 26, 2008 4:29 PM
> To: ivy-user@ant.apache.org
> Subject: Re: dynamically modifying dependency versions during resolve
>
> On Thu 2008-06-26 at 17:18h, Ernest Pasour wrote on ivy-user:
> > I am trying to modify an ivy system to have special resolve handling
> > at development time. My goal is to add another resolver (R1) before
> > the published repository that will *always* find a module if any
> > version of that module exists in R1.
> >
> > Ex. The repository denoted by R1 contains modules E3 and F3
> > The published repository contains modules A1 B1 C1 D1 E1 F1 G1
> > G1 depends upon F1 explicitly in its Ivy file.
> >
> > So when a build happens and G1 is resolved, I want R1 to get in the
> > way and say, "No, I don't have F1, but I do have F3, so that's what
> > I'll return".
> >
> > What is the best way (if any) to accomplish this?
>
> Maybe you could explain why you want this behavior.
> There may be other, simpler ways to achieve your actual goal.
>
> -- 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.
RE: dynamically modifying dependency versions during resolve
Posted by Shawn Castrianni <Sh...@halliburton.com>.
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.
Re: dynamically modifying dependency versions during resolve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2008-06-26 at 18:13h, Jim Adams wrote on ivy-user:
> > 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.
>
> 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.
As I wrote above, the change is normally necessary anyway, so yes I
want that change to be published eventually.
Another thing we sometimes do is that we move attributes from the Ivy
file to a build.properties file when there's a need for them to
sometimes be locally overridden. Users have a build.local.properties
file where they can override these properties. Something similar could
probably be done at the XML level.
-- Niklas Matthies
RE: dynamically modifying dependency versions during resolve
Posted by Jim Adams <Ji...@sas.com>.
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
RE: dynamically modifying dependency versions during resolve
Posted by Jim Adams <Ji...@sas.com>.
You are not alone!
________________________________________
From: Shawn Castrianni [Shawn.Castrianni@halliburton.com]
Sent: Thursday, June 26, 2008 9:48 PM
To: ivy-user@ant.apache.org
Subject: RE: dynamically modifying dependency versions during resolve
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. If I checkin to C without testing this, then I have to wait for the next build of C and then the next build of B and then the next build of A which might break. This build of A might take place after I leave work for the day. Now A is failing all night long until I come to work in the morning to discover how much damage I caused overnight. I would rather make changes to C and test against A before checking in to C. If A breaks, then I can fix A too locally on my machine. Then I checkin both A and C. Then the next build of C and B and A will work. If A builds first before C and B, it might break because C hasn't built yet, but it will fix itself overnight without me having to worry about it.
I can't believe Ernest Pasour and myself are the only ones needing this behavior.
---
Shawn Castrianni
-----Original Message-----
From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 8:25 PM
To: ivy-user@ant.apache.org
Subject: Re: dynamically modifying dependency versions during resolve
On Thu 2008-06-26 at 19:18h, Shawn Castrianni wrote on ivy-user:
> No, I want to test A against a dependency way down in the hierarchy.
> Why should I have to make A be directly dependent on H when it is
> already indirectly dependent on H?
Because A is not (indirectly) dependent on plain H, but dependent on a
particular revision of H. If you want to test A against a different
revision than the one A effectively depends on, you have to specify
that information for the resolution process of A specifically. The
resolution process of A is defined by A's ivy.xml (and the settings),
so it seems like the most suitable place for that information (besides
the settings).
> Maybe this comes down to how one should specify ivy dependencies.
> It sounds like you are saying that if A needs to be tested against a
> change in H, then that must mean that A has a direct dependency on H
> in the code so it should be declared that way in A's ivy.xml file.
Not quite. What I'm saying is that the existing dependency chain from
A to H does not point to the revision of H you want to test against.
Let's go back to the A->B->C example for the moment as that's a bit
easier to work with :). So, you have an ivy.xml sitting there for A
which says that A depends on the lastest B revision. Let's say the
latest published B revision is B1, and its ivy.xml says that it
depends on C1. So the dependencies effectively declared by A's ivy.xml
are A->B1->C1. But you want to test with C2. Well, tough luck ;), but
that's a different revision than the one A transitively depends on.
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?
> I have purposely removed all unnecessary direct dependencies if a
> dependency will get picked up indirectly. This removes a lot of
> conflicts that can occur during dependency resolution. So even
> though A may call a function in H making it directly dependent on
> it, I have purposely not made H a direct dependency of A because it
> will get it indirectly through B. My philosophy produces cleaner
> dependency graphs and prevents lots of modifications to ivy.xml
> files to try to keep ivy dependencies in sync with the actual code
> dependencies. A should be able to make function calls to B, C, D,
> E, F, G, and H without having to be directly dependent on them in
> its ivy.xml file.
It depends. If the function calls made by A to H are not inherently
due to to A's use of B, then A should quite likeley have its own
dependency on H. But that is a bit beside the point.
Maybe the relevant point is that dependency resolution for building a
module X and the published dependencies of module X (for the purpose
of *using* module X) are two different[1] things not only for the
direct dependencies of X but for its transitive dependencies as well.
So the problem with Ivy might be that it only specifically makes that
distinction for direct dependencies (resolved ivy.xml vs. non-resolved
ivy.xml). My feeling is that all the resolution override features are
basically attempts at addressing this problem. But whichever way one
looks at it, making a different choice for transitive dependencies at
build time implies that the choice needs to specified for whatever is
being built, which means that it becomes non-transitive at that point,
because (this is almost too trivial) the intermediate dependencies are
already built and hence not part of what is being built. Of course it
might be specified generically as "upgrade all transitive dependencies
to the latest revision", but it still means that changes(!) to the
transitive dependencies are being specified at the "root" module.
[1] To elabotarate on the distinction: The published dependencies
specify "what am I compatible with" or "what do I require at least",
whereas the build/packaging dependencies specify "what do I actually
want to have included in the build". Of course the latter is, or
should be, constrained by the former, but it's nevertheless a separate
choice, and one for which it doesn't matter whether a dependency is
transitive or direct.
-- 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.
Re: dynamically modifying dependency versions during resolve
Posted by Xavier Hanin <xa...@gmail.com>.
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:
https://issues.apache.org/jira/browse/IVY-857
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"*>
<ivy
pattern="${ivy.settings.dir}/local/[module]/[revision]/ivy.xml"/>
<artifact
pattern="${ivy.settings.dir}/local/[module]/[revision]/[artifact].[ext]"/>
</filesystem>
Xavier
On Fri, Jun 27, 2008 at 3:42 PM, Shawn Castrianni <
Shawn.Castrianni@halliburton.com> 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 [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 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 [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 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
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: dynamically modifying dependency versions during resolve
Posted by Shawn Castrianni <Sh...@halliburton.com>.
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 [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 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 [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 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.
RE: dynamically modifying dependency versions during resolve
Posted by Ernest Pasour <Er...@sas.com>.
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 [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 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
Re: dynamically modifying dependency versions during resolve
Posted by Niklas Matthies <ml...@nmhq.net>.
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
RE: dynamically modifying dependency versions during resolve
Posted by Shawn Castrianni <Sh...@halliburton.com>.
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. If I checkin to C without testing this, then I have to wait for the next build of C and then the next build of B and then the next build of A which might break. This build of A might take place after I leave work for the day. Now A is failing all night long until I come to work in the morning to discover how much damage I caused overnight. I would rather make changes to C and test against A before checking in to C. If A breaks, then I can fix A too locally on my machine. Then I checkin both A and C. Then the next build of C and B and A will work. If A builds first before C and B, it might break because C hasn't built yet, but it will fix itself overnight without me having to worry about it.
I can't believe Ernest Pasour and myself are the only ones needing this behavior.
---
Shawn Castrianni
-----Original Message-----
From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 8:25 PM
To: ivy-user@ant.apache.org
Subject: Re: dynamically modifying dependency versions during resolve
On Thu 2008-06-26 at 19:18h, Shawn Castrianni wrote on ivy-user:
> No, I want to test A against a dependency way down in the hierarchy.
> Why should I have to make A be directly dependent on H when it is
> already indirectly dependent on H?
Because A is not (indirectly) dependent on plain H, but dependent on a
particular revision of H. If you want to test A against a different
revision than the one A effectively depends on, you have to specify
that information for the resolution process of A specifically. The
resolution process of A is defined by A's ivy.xml (and the settings),
so it seems like the most suitable place for that information (besides
the settings).
> Maybe this comes down to how one should specify ivy dependencies.
> It sounds like you are saying that if A needs to be tested against a
> change in H, then that must mean that A has a direct dependency on H
> in the code so it should be declared that way in A's ivy.xml file.
Not quite. What I'm saying is that the existing dependency chain from
A to H does not point to the revision of H you want to test against.
Let's go back to the A->B->C example for the moment as that's a bit
easier to work with :). So, you have an ivy.xml sitting there for A
which says that A depends on the lastest B revision. Let's say the
latest published B revision is B1, and its ivy.xml says that it
depends on C1. So the dependencies effectively declared by A's ivy.xml
are A->B1->C1. But you want to test with C2. Well, tough luck ;), but
that's a different revision than the one A transitively depends on.
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?
> I have purposely removed all unnecessary direct dependencies if a
> dependency will get picked up indirectly. This removes a lot of
> conflicts that can occur during dependency resolution. So even
> though A may call a function in H making it directly dependent on
> it, I have purposely not made H a direct dependency of A because it
> will get it indirectly through B. My philosophy produces cleaner
> dependency graphs and prevents lots of modifications to ivy.xml
> files to try to keep ivy dependencies in sync with the actual code
> dependencies. A should be able to make function calls to B, C, D,
> E, F, G, and H without having to be directly dependent on them in
> its ivy.xml file.
It depends. If the function calls made by A to H are not inherently
due to to A's use of B, then A should quite likeley have its own
dependency on H. But that is a bit beside the point.
Maybe the relevant point is that dependency resolution for building a
module X and the published dependencies of module X (for the purpose
of *using* module X) are two different[1] things not only for the
direct dependencies of X but for its transitive dependencies as well.
So the problem with Ivy might be that it only specifically makes that
distinction for direct dependencies (resolved ivy.xml vs. non-resolved
ivy.xml). My feeling is that all the resolution override features are
basically attempts at addressing this problem. But whichever way one
looks at it, making a different choice for transitive dependencies at
build time implies that the choice needs to specified for whatever is
being built, which means that it becomes non-transitive at that point,
because (this is almost too trivial) the intermediate dependencies are
already built and hence not part of what is being built. Of course it
might be specified generically as "upgrade all transitive dependencies
to the latest revision", but it still means that changes(!) to the
transitive dependencies are being specified at the "root" module.
[1] To elabotarate on the distinction: The published dependencies
specify "what am I compatible with" or "what do I require at least",
whereas the build/packaging dependencies specify "what do I actually
want to have included in the build". Of course the latter is, or
should be, constrained by the former, but it's nevertheless a separate
choice, and one for which it doesn't matter whether a dependency is
transitive or direct.
-- 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.
Re: dynamically modifying dependency versions during resolve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2008-06-26 at 19:18h, Shawn Castrianni wrote on ivy-user:
> No, I want to test A against a dependency way down in the hierarchy.
> Why should I have to make A be directly dependent on H when it is
> already indirectly dependent on H?
Because A is not (indirectly) dependent on plain H, but dependent on a
particular revision of H. If you want to test A against a different
revision than the one A effectively depends on, you have to specify
that information for the resolution process of A specifically. The
resolution process of A is defined by A's ivy.xml (and the settings),
so it seems like the most suitable place for that information (besides
the settings).
> Maybe this comes down to how one should specify ivy dependencies.
> It sounds like you are saying that if A needs to be tested against a
> change in H, then that must mean that A has a direct dependency on H
> in the code so it should be declared that way in A's ivy.xml file.
Not quite. What I'm saying is that the existing dependency chain from
A to H does not point to the revision of H you want to test against.
Let's go back to the A->B->C example for the moment as that's a bit
easier to work with :). So, you have an ivy.xml sitting there for A
which says that A depends on the lastest B revision. Let's say the
latest published B revision is B1, and its ivy.xml says that it
depends on C1. So the dependencies effectively declared by A's ivy.xml
are A->B1->C1. But you want to test with C2. Well, tough luck ;), but
that's a different revision than the one A transitively depends on.
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?
> I have purposely removed all unnecessary direct dependencies if a
> dependency will get picked up indirectly. This removes a lot of
> conflicts that can occur during dependency resolution. So even
> though A may call a function in H making it directly dependent on
> it, I have purposely not made H a direct dependency of A because it
> will get it indirectly through B. My philosophy produces cleaner
> dependency graphs and prevents lots of modifications to ivy.xml
> files to try to keep ivy dependencies in sync with the actual code
> dependencies. A should be able to make function calls to B, C, D,
> E, F, G, and H without having to be directly dependent on them in
> its ivy.xml file.
It depends. If the function calls made by A to H are not inherently
due to to A's use of B, then A should quite likeley have its own
dependency on H. But that is a bit beside the point.
Maybe the relevant point is that dependency resolution for building a
module X and the published dependencies of module X (for the purpose
of *using* module X) are two different[1] things not only for the
direct dependencies of X but for its transitive dependencies as well.
So the problem with Ivy might be that it only specifically makes that
distinction for direct dependencies (resolved ivy.xml vs. non-resolved
ivy.xml). My feeling is that all the resolution override features are
basically attempts at addressing this problem. But whichever way one
looks at it, making a different choice for transitive dependencies at
build time implies that the choice needs to specified for whatever is
being built, which means that it becomes non-transitive at that point,
because (this is almost too trivial) the intermediate dependencies are
already built and hence not part of what is being built. Of course it
might be specified generically as "upgrade all transitive dependencies
to the latest revision", but it still means that changes(!) to the
transitive dependencies are being specified at the "root" module.
[1] To elabotarate on the distinction: The published dependencies
specify "what am I compatible with" or "what do I require at least",
whereas the build/packaging dependencies specify "what do I actually
want to have included in the build". Of course the latter is, or
should be, constrained by the former, but it's nevertheless a separate
choice, and one for which it doesn't matter whether a dependency is
transitive or direct.
-- Niklas Matthies
RE: dynamically modifying dependency versions during resolve
Posted by Shawn Castrianni <Sh...@halliburton.com>.
No, I want to test A against a dependency way down in the hierarchy. Why should I have to make A be directly dependent on H when it is already indirectly dependent on H?
Maybe this comes down to how one should specify ivy dependencies. It sounds like you are saying that if A needs to be tested against a change in H, then that must mean that A has a direct dependency on H in the code so it should be declared that way in A's ivy.xml file. I have purposely removed all unnecessary direct dependencies if a dependency will get picked up indirectly. This removes a lot of conflicts that can occur during dependency resolution. So even though A may call a function in H making it directly dependent on it, I have purposely not made H a direct dependency of A because it will get it indirectly through B. My philosophy produces cleaner dependency graphs and prevents lots of modifications to ivy.xml files to try to keep ivy dependencies in sync with the actual code dependencies. A should be able to make function calls to B, C, D, E, F, G, and H without having to be directly dependent on them in its ivy.xml file.
---
Shawn Castrianni
-----Original Message-----
From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 6:06 PM
To: ivy-user@ant.apache.org
Subject: Re: dynamically modifying dependency versions during resolve
On Thu 2008-06-26 at 17:16h, Shawn Castrianni wrote on ivy-user:
> Yes, but imagine a huge corporate environment with stupid
> developers. Imagine A->B->C->D->E->F->G->H. If a developer changes
> H and wants to test against A,
So he wants to test A against different(!) dependencies than those
currently declared by A. I don't know, but I think it's a matter of
course that this intent then needs to be expressed explicitly
somewhere.
> I don't want him to have to build and locally publish B through G.
> Plus, I don't want to have to teach my developers xml and ivy and
> how to hack their ivy.xml to make H a direct dependency of A.
But for the use case at hand, it effectively _is_ a direct dependency
of the version of A the developer wants to build. So I don't exactly
see what's wrong about specifying it in the ivy file.
It seems to me that the real issue is separating local build
configurations from the "official" build configurations published to
source revision control and to the public ivy repository.
-- 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.
Re: dynamically modifying dependency versions during resolve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2008-06-26 at 17:16h, Shawn Castrianni wrote on ivy-user:
> Yes, but imagine a huge corporate environment with stupid
> developers. Imagine A->B->C->D->E->F->G->H. If a developer changes
> H and wants to test against A,
So he wants to test A against different(!) dependencies than those
currently declared by A. I don't know, but I think it's a matter of
course that this intent then needs to be expressed explicitly
somewhere.
> I don't want him to have to build and locally publish B through G.
> Plus, I don't want to have to teach my developers xml and ivy and
> how to hack their ivy.xml to make H a direct dependency of A.
But for the use case at hand, it effectively _is_ a direct dependency
of the version of A the developer wants to build. So I don't exactly
see what's wrong about specifying it in the ivy file.
It seems to me that the real issue is separating local build
configurations from the "official" build configurations published to
source revision control and to the public ivy repository.
-- Niklas Matthies
RE: dynamically modifying dependency versions during resolve
Posted by Ernest Pasour <Er...@sas.com>.
Yes, exactly. It is prohibitive from a time standpoint to republish *all* of the modules locally.
-----Original Message-----
From: Shawn Castrianni [mailto:Shawn.Castrianni@halliburton.com]
Sent: Thursday, June 26, 2008 6:16 PM
To: 'ivy-user@ant.apache.org'
Subject: RE: dynamically modifying dependency versions during resolve
Yes, but imagine a huge corporate environment with stupid developers. Imagine A->B->C->D->E->F->G->H. If a developer changes H and wants to test against A, I don't want him to have to build and locally publish B through G. Plus, I don't want to have to teach my developers xml and ivy and how to hack their ivy.xml to make H a direct dependency of A. I want it to be smooth and transparent and automatic and AWESOME like ivy is!
---
Shawn Castrianni
-----Original Message-----
From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 5: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.
RE: dynamically modifying dependency versions during resolve
Posted by Shawn Castrianni <Sh...@halliburton.com>.
Yes, but imagine a huge corporate environment with stupid developers. Imagine A->B->C->D->E->F->G->H. If a developer changes H and wants to test against A, I don't want him to have to build and locally publish B through G. Plus, I don't want to have to teach my developers xml and ivy and how to hack their ivy.xml to make H a direct dependency of A. I want it to be smooth and transparent and automatic and AWESOME like ivy is!
---
Shawn Castrianni
-----Original Message-----
From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 5: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.
Re: dynamically modifying dependency versions during resolve
Posted by Niklas Matthies <ml...@nmhq.net>.
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
RE: dynamically modifying dependency versions during resolve
Posted by Shawn Castrianni <Sh...@halliburton.com>.
My guess is he wants what I want which I described in a previous mailing list post. I would like to be able to setup a local repository that developers can locally publish to that takes precedence over any published module in the real repository. That way a developer that is working on multiple modules at one time, can build the first one and publish it locally as version "LOCAL" or something. Then he can switch to a higher level module and when resolving, it will pick up the locally published module first instead of the one on the repository that is specified in the transitive ivy.xml files. This allows developers to test source code across multiple modules before having to checkin anything and wait for an official build from some automated server.
Now you might think, this is already supported with a chained resolver returnFirst="true". That would be true except for the revision number. The locally published module may not have the same revision number that a transitive resolve would find. Therefore, it would skip the locally published module since "LOCAL" isn't what it is looking for. I think we both want the locally published module to take precedence regardless of what the revision is.
Currently the only way to do this is to turn on resolveMode="dynamic" for that module. But the problem with this is I don't want resolveMode="dynamic" turned on ALL the time. I just want it on when there is a localy published module. So I need to be able to programmatically know at runtime whether to have resolveMode="dynamic" based on whether a locally published module exists.
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.
---
Shawn Castrianni
-----Original Message-----
From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
Sent: Thursday, June 26, 2008 4:29 PM
To: ivy-user@ant.apache.org
Subject: Re: dynamically modifying dependency versions during resolve
On Thu 2008-06-26 at 17:18h, Ernest Pasour wrote on ivy-user:
> I am trying to modify an ivy system to have special resolve handling
> at development time. My goal is to add another resolver (R1) before
> the published repository that will *always* find a module if any
> version of that module exists in R1.
>
> Ex. The repository denoted by R1 contains modules E3 and F3
> The published repository contains modules A1 B1 C1 D1 E1 F1 G1
> G1 depends upon F1 explicitly in its Ivy file.
>
> So when a build happens and G1 is resolved, I want R1 to get in the
> way and say, "No, I don't have F1, but I do have F3, so that's what
> I'll return".
>
> What is the best way (if any) to accomplish this?
Maybe you could explain why you want this behavior.
There may be other, simpler ways to achieve your actual goal.
-- 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.
Re: dynamically modifying dependency versions during resolve
Posted by Niklas Matthies <ml...@nmhq.net>.
On Thu 2008-06-26 at 17:18h, Ernest Pasour wrote on ivy-user:
> I am trying to modify an ivy system to have special resolve handling
> at development time. My goal is to add another resolver (R1) before
> the published repository that will *always* find a module if any
> version of that module exists in R1.
>
> Ex. The repository denoted by R1 contains modules E3 and F3
> The published repository contains modules A1 B1 C1 D1 E1 F1 G1
> G1 depends upon F1 explicitly in its Ivy file.
>
> So when a build happens and G1 is resolved, I want R1 to get in the
> way and say, "No, I don't have F1, but I do have F3, so that's what
> I'll return".
>
> What is the best way (if any) to accomplish this?
Maybe you could explain why you want this behavior.
There may be other, simpler ways to achieve your actual goal.
-- Niklas Matthies