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