ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Widmer <tom.wid...@googlemail.com>
Subject Re: making an SCM managed copy of your external artifacts
Date Tue, 10 Aug 2010 17:10:28 GMT
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

In hindsight, I think a better approach would be to use something like 
Artifactory to manage the repos (since it automates Maven mirroring in a 
configurable way, and also handles ivy artifacts), and set up 3 repos 
inside it:

1. repo/external/maven, for everything that comes from public maven 
repos (probably using Artifactory). This is a controlled pure maven 
mirror. The benefit of keeping the metadata as maven metadata is that as 
Ivy gets better at processing Maven metadata, you get the benefit, 
rather than being stuck with the potentially erroneous ivy metadata you 
got when you originally installed the software to the repo.
2. repo/external/ivy, for everything external not available in public 
maven repos, or not readily convertable to maven. You'll probably 
hand-craft local ivy.xml files for things in here, and the publish them 
and the artefacts to the repo.
3. repo/internal/ivy for internally published artifacts.

Tom


Mime
View raw message