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 to
artifact>
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
unfortunately)
Tom
