That is when you combine the power of a chained resolver and the relatively new "force" feature of a resolver. You create a local repository resolver in your setting file that has force="true". You then create a chained resolver where the first one is the local repository resolver followed by your main repository resolver. You create an ANT target called publish.local (or whatever) that publishes A locally using the local resolver, then when you go to B and do a resolve/retrieve, the local A is grabbed because of the "force" instead of the published one in the ivy repo. Now in this particular example, force="true" is not actually needed. But you will need it with a more complex example like: C->B->A where you are trying to build C with the published B and a local A. Without force="true", the A retrieved will be the transitive dependency of the version of B found in the main repo and not your local A.
--- Shawn Castrianni -----Original Message----- From: Viktor Sadovnikov [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 2:24 AM To: [email protected] Subject: Re: Resolver or dependency Yes, it works great with CI server. However I am aiming to help developers to test their code changes in both projects locally. Changed project A is not published yet (even locally), but developer is executing "ant test" of project B. Now it fails. ----- Original Message ---- From: Mitch Gitman <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, November 13, 2008 3:44:10 PM Subject: Re: Resolver or dependency If project B depends on project A, then the only knowledge B has of the latest version of A is what's in the Ivy repository that the Ivy resolver is using. When you get right down to it, the extra functionality you're looking for is really the work of a continuous integration system. The sequence would go like this: 1. You check in changes to project A to source control. 2. A CI system like Hudson detects the change to A and proceeds to build the project itself. 3. At this end of a successful build, Hudson publishes A.jar (or whatever the artifacts are) to the Ivy repository in use. 4. If you're using something like the Hudson Ivy plugin, then a change to project A will trigger a rebuild of its dependent project, B. By the way, does anyone know the current state of the Hudson Ivy plugin when it comes to Ivy 2.0? On Thu, Nov 13, 2008 at 4:49 AM, Viktor Sadovnikov <[EMAIL PROTECTED]>wrote: > Hi everyone, > > Seems I am either making fundamental mistake in understanding Ivy or > missing > something. How should I setup compilation when I have two projects: A and > B, > the last one depends on the latest version of A. > My setup is based on "multi-project" example, which comes > with Ivy. Code of both projects is changed locally and I want to test > compilation of B. Both "compile" of B and "compile-all" fail until A is > published. I would expect something in either "dependencies" of B or > resolvers > to tell Ivy that A needs to be rebuild. > > Could anyone point me to my mistake? > > Thanks a lot, > Viktor > > > >
