I can't think of anything technically wrong with the solution Shawn describes, although I would hate to add a resolver to a project's Ivy settings just for the sake of some developer scratchpad testing. If the goal really is just testing the interaction between two projects before you check either of them in, typically I have done either of the following:
- If I'm using Eclipse as my IDE, I would make project B depend directly on project A, rather than letting B depend on A through what IvyDE provides. If you do this, though, you need to make sure that the B classpath dependency shows up above the IvyDE classpath dependency. - If I'm trying to test something outside of IvyDE, I build project A. Then I take the JAR I just built and I place it in the latest version location in my local Ivy cache. If the version shows up in the filename, I may need to tweak that. The latter approach feels a bit hacky, but it works. Either way, once your tests of B work with the A dependencies, you can check in both projects simultaneously if you wish. Well, if you check in simultaneously and you're using a CI server, you're going to have to get A to build first on the CI server. On Fri, Nov 14, 2008 at 2:45 AM, Shawn Castrianni < [EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > >
