Your question is a bit ambiguous, so let me not so much answer it as make two points to get the terminology and concepts straight.
When you talk about skipping the resolution of the external artifacts, what you really should be saying is that you're still doing an ivy:resolve, just you're trusting the modules in the Ivy cache are up-to-date and Ivy doesn't have to check the remote repository again. This is the default behavior, and the natural behavior for external libraries and released versions of internal libraries. For internal libraries still under development, you want to override this so that Ivy always checks the repo. Typically, this is done on the resolver in ivysettings.xml, and I can think of three criteria you can pass to the resolver to say that it's an "integration" version: - The publication status in the ivy.xml is "integration" or something comparable. - There's a special suffix in the version, like -SNAPSHOT or a buildnumber or timestamp. - The modules are in a special integration repository directory. It's not a bad idea to do all three in combination, although any one will do. See: http://ant.apache.org/ivy/history/latest-milestone/concept.html#change When you talk about using Ivy resolve to tell if A has been rebuilt triggering a new build of B, you're applying concepts that apply not to a dependency manager like Ivy but rather to a continuous integration server like Jenkins. Forgive me if I'm stating something you're already well aware of, but the way that a change in A triggers a build of B is to have the CI server monitor for check-ins to the different projects. If someone commits a change to A, it triggers a build of A, and if that build is succeeding, a new version of the A artifact gets published to the repository. From here, the CI server should be configured (whether manually or through an Ivy integration) to have a successful build of A trigger a build of B. From here, B is assured to get the latest A that was just published. Your question implies CI builds as opposed to developer builds, since the developer knows what projects they've changed or have incoming changes from source control. On Thu, Sep 6, 2012 at 4:12 AM, wellgoonthen <richcol...@googlemail.com>wrote: > > Hi, > > I'm currently doing some build doctor work on our system build. I've done > quite a lot of work to implement a java incremental set up using uptodate > etc. This is great and saves a lot of time/work. The biggest issue is now > the ivy resolution. To summarise we have two types dependencies that I > call: > > - External - junit, log4j etc. > - Internal - intra build module artifacts > > Now I can easily skip the resolution of the external artifacts by checking > the "uptodateness" of the modules ivy.xml file to see if the version of > junit has been changed, or a new 3rd party lib added to that module. The > issue I have is with the internal dependencies. > > For example if my build consists of modules A -> B -> C, built in that > order. I currently have to rely on ivy resolve to know if A's artifact has > been rebuilt which would therefore trigger a rebuild of B. > > To summarise I'm using ivy:resolve to do this and for one module that takes > a total of 11 seconds, 8 seconds is spent resolving stuff. > > Does anyone have any ideas on this? > > Many thanks > > Richard Cole > -- > View this message in context: > http://old.nabble.com/External-vs.-Internal-dependencies-tp34396743p34396743.html > Sent from the ivy-user mailing list archive at Nabble.com. > >
