ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Widmer <>
Subject Re: making an SCM managed copy of your external artifacts
Date Wed, 11 Aug 2010 15:32:13 GMT
Tom Widmer wrote:
> Steve Loughran wrote:
>> I want to set up a project which has all the things we depend on in 
>> SCM, plan is to have two repositories
>> repo/internal  - in house built artifacts, SCM managed release 
>> propagation, etc.
>> repo/external - everything that normally comes out of ibiblio, jboss, 
>> reslet m2 repositories, which ivy pulls down, and the odd Sun JAR that 
>> isn't normally online
>> Question is, how best to build that external repository, especially, 
>> how best to automate building that repository.
>> 1. Manual M2 layout. From the dependency data, grab the JARs and POM 
>> files, lay them out maven style.
>> 2. Copy ivy cache. clean your local cache, do a release, copy 
>> ~/.ivy/cache to repo/external, delete things you don't want there and 
>> check in the rest.
>> Has anyone else done this? What was their tactic?
> Originally, I had plans of having lovely pristine ivy metadata for all 
> our external libraries, but in the end that would simply have been too 
> time consuming, so I now just import the maven metadata into our ivy 
> repository in whatever form ivy:install puts it.
> I install new things into the external (SVN) repo using an ant script. e.g.
> ant -Dorg=org.apache -Dmodule=whatever -Drev=1.2.3

I should also mention that our own artifacts don't get explicitly 
published. Instead, I've set up our ivy settings to point directly to 
the artifacts where they appear on our TeamCity build server. This has 
the benefit that TeamCity can automatically delete old artifacts that we 
don't want (it has per-build-configuration rules for doing this), and 
also that TeamCity tracks dependencies between builds correctly (a bit 
like Hudson's fingerprinting) since it notices exactly what other build 
artifacts are downloaded by the dependent build (and avoids deleting 
builds that are depended on).

The main limitation to this approach is that ideally I need to write a 
custom resolver to work with TeamCity. The URLs are of the form:

<url>/<build project>::<build configuration>/<build number>/<path

which isn't quite a perfect match for ivy's 
organisation/module/branch/revision/artifact breakdown.

(in the end I used a pretty strange mapping between them which works 
well enough for our purposes, though doesn't allow 'latest.rev' to work 


View raw message