ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From osbald <>
Subject Re: New user questions
Date Mon, 14 Jan 2008 15:19:07 GMT

Thanks for taking the time to reply.

>> 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

>Have you read the cache and change management doc:

OK I think I get that. I'd assumed when I publish the artefact in question
would simply go into the cache and it was the lookups that'd use the cache.
I suppose I need to version our modules. It's just one of the things I'd
hoped to put off until I understood Ivy better. Modifying the
changingPattern and changingMatcher also sound interesting, I suppose I
could make these match no-version and snapshot  versions although I'm still
shy of messing with the default configuration too much in these early

>> 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). 

>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. 

Thats pretty much what I was thinking, but I'm the most experienced
developer here 
(but critically not the boss nor team lead) and changing too much will just
lead to 
masses of confusion and my build script being abandoned (been here before).
We don't 
have any shared resources except the svn repository and people work at home
on laptops
(no access to the svn even ~ have to email them updates). I'm still trying
sneak in small course adjustments rather hit them with a big reorg.

The management of the ivy files alongside any IDE changes I'll just have to
live with. At
first glance having to explicitly list all 3rd party jars and versions seems
more fragile than
including a jar directory under IDEA IDE or an Ant fileset. But it's the
transitive details and
Ivy configurations which I'm hoping will solve some really knotty issues
with our distributions 
the IDE is largely unconcerned with.

I tried creating a chained resolver to pick these up, but found out [module]
isn't replaced with
the module of the ivy.xml they're defined in but what I'd call the artifact
name? Wasn't sure I 
could use wildcards in these patterns like I might with Ant so I'm thinking
of creating a new 
attribute to state which module lib they can be found in.. pending a change
to a shared, 
structured lib folder/repository that is.

  <filesystem name="local">

Wasn't sure there isn't another way to pick these up from our existing
project structure.

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

View raw message