Ivy in the build

Steve Loughran <[email protected]> Tue, 19 Dec 2006 15:24:13 +0000
Newsgroups gmane.comp.java.smartfrog.devel
Message-ID <[email protected]>
Anyone checking out and building from the SVN repo will now see that we 
are using Ivy to manage dependencies, both external and internal. Ivy 
pulls down any JARs it needs based on the version properties in 
core/components/libraries.properties, using the ivy.xml files to define 
which artifacts every component depends on.

The external files come from the big maven2 repository, 
http://ibiblio.org/maven2 ; there is a good search tool  for locating 
things on it : http://mvnrepository.com/ . These files are downloaded 
into a local cache, ${user.home}/.ivy/cache, so are only downloaded once.

Internal dependencies are dealt with by publishing the artifacts to a 
local cache ${user.home}/.ivy/local, so any component that builds has to 
stick its JARs into this repository, which the ivy:publish task does for 
us. All components have a "published" target which sticks all the 
artifacts to this repository.

Right now I've redone how we build the JARs, but havent integrated 
source and binary redistributions into the process. Ultimately these 
will be created for every project and published to the repository too. 
We will have to move away from the 'unified source bundle' that we used 
to make, because that doesnt scale; already it has problems and once we 
have multiple components with conflicting JAR dependencies it breaks.

I have set the build up so that you dont need an ivy.jar in the 
classpath, though on ant1.6.x you may get (harmless) warnings about 
redeclarations of a task.

What does this mean?

1. It means I have some more build process documentation todo. Email me 
if you want the ivy chapter of Ant in Action, which will have to 
suffice, for now.

2. It means that the versions of JARs in the component lib/ directories 
are irrelevant (except for redistribution, and I havent gone after that 
yet). We are being driven off version properties which are set in 
components/libraries.properties but which can be set on a per-component 
basis

3. it means the first build needs to be with network access.

4. it means you need to set up your Ant proxy options right, to get 
through any proxy you have. Here's mine:

bash:
export ANT_OPTS=-Dhttp.proxyHost=web-proxy -Dhttp.proxyPort=8088
tcsh/csh
setenv ANT_OPTS-Dhttp.proxyHost=web-proxy -Dhttp.proxyPort=8088

windows, set the ANT_OPTS env variable to something similar.

5. If you have any external projects you want to integrate with the 
ivy-based build; place them under core/external with an ivy.xml file 
alongside their build.xml file. Ivy will then add them to the build in 
an order that integrates with all other artifacts generated in the sambe 
build

Ivy does improve our build process. not only can it pull down things we 
need, it can work out how to build files in the right order. If you want 
to see this at work. in the core/ directory, go

	ant published

to get everything published. That includes all projects and components 
(except for the CDDLM ones that only build with ivy-cddlm). You can also 
go "ant ivy-report"  to get a nice report of all your dependencies, 
which is good for learning what is going on.

No doubt some things will break. Please let me know what they are and 
I'll work with you to get your build going again. Most likely it will be 
proxy settings.

-steve


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV