ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: New user questions
Date Mon, 14 Jan 2008 09:33:54 GMT
On Jan 11, 2008 11:54 AM, osbald <> wrote:

> Hi I'm new to Ivy and I'm trying to retrofit Ivy onto an pre-existing
> multi-module project. I've started with the multi-modules example and I've
> got it mostly working at the module level. Although there's a couple of
> points causing me to wonder.
> First is I'm publishing to a shared repository directory much like the
> example. But I've noticed when I publish the jar produced doesn't seem to
> get into the ivy cache. Or at least when I compile a dependant module the
> jar the resolve retrieves is an older copy from the cache not the one most
> recently built and in my shared repository? Currently I've bee wiping my
> .ivy2/cache directory on every build which obviously isn't right. What I
> suspect may be wrong is our modules don't have any versions - so I
> hardcoded
> the publish tasks pubversion to be "snapshot" what should I be doing here?

Have you read the cache and change management doc:

> Next question is on these modules transitive dependencies(?). What I mean
> is
> our pre-existing project keeps its module dependencies in a lib directory
> underneath each module/project dir (alongside src). Pretty standard stuff
> and I was wondering how to bridge using Ivy in this environment and wheter
> it is worth it? What I thought I could do was define a resolver to pickup
> any jars the local module needs. Although the naming convention may give
> me
> some headaches. Of course I could get Ivy to resolve all 3rd party jars
> from
> online public repository, although several of these jars I'm using either
> aren't in maven at all - or an older version. Plus it's more amenable to
> our
> IDE having the jars available on checkout without having to call a "ant
> resolve-all" target before opening the project. Does this approach make
> sense, is it possible to use an ad-hoc approach. I'm aware that without
> support (IDEA in this case) maintaining the modules Ivy.xml with the
> contents of it's lib directories may prove to be a pain. This is where my
> build currently fails trying to resolve module jars - because the
> multi-project dosn't have locally sourced jars/dependencies and doesn't
> have
> an IvySettings.xml to define resolvers. Don't suppose there's any examples
> of this kind of configuration anywhere?

IMO it's really worth it to manage your third party dependencies with Ivy
instead of keeping your lib directories unmanaged. But this is a time
consuming effort, and some projects can't afford it. In this case I'd say
you can just stick with Ivy managing your own module dependencies, and keep
your lib directory for third party deps. But this mean that you will still
have the problems of update of the lib directory when a module dependency
introduce a new third party dependency. Or maybe you can use Ivy for new
third party dependencies only, and merge this result with what you already
in your lib directory. Not very clean but can be a pragmatic solution. In
any case, we don't recommend using maven public repository directly, see why
on our best practices page.


> - Richard
> --
> View this message in context:
> Sent from the ivy-user mailing list archive at

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message