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: >http://ant.apache.org/ivy/history/latest-milestone/concept.html#cache 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 attempts. >> 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 to 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"> <artifact pattern="${project.basedir}/modules/[module]/lib/[artifact](-[revision]).[ext]"/> <ivy pattern="${project.basedir}/modules/[module]/lib/[artifact](-[revision]).xml"/> </filesystem> Wasn't sure there isn't another way to pick these up from our existing project structure. - Richard -- View this message in context: http://www.nabble.com/New-user-questions-tp14753643p14803672.html Sent from the ivy-user mailing list archive at Nabble.com.
