forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [PROPOSAL] Switch dependency managment to IVY
Date Thu, 22 Feb 2007 10:30:18 GMT
David Crossley wrote:
> Ross Gardler wrote:
>> Ross Gardler wrote:
>>> Here is my plan:
>>> 1 - I create a Forrest only repo in SVN (as I have started for
>>> Forrest2). although wherever possible we will use the IVY repo and the
>>> Maven2 repo
>>> 2 - I modify our build files to use IVY (I have a whole set of generic
>>> build files that are intended to be extended by project specific build
>>> files. I plan to give them to the IVY folk if they think it they are a
>>> good idea, if not we'll take what we need from them)
>>> 3 - We make sure it works
>>> 4 - We move the entries in our repo to the IVY repo (I need to enter
>>> into a dialogue with IVY devs to see what is happening with regards an
>>> official Apache repo)


> I want to assist. Some initial questions ...

Cool. As you have seen my work on this has frozen due to other 
commitments. Should be getting back to it soon.

> I see that you have Ivy module descriptors, e.g.
> tools/ivy/repository/apache/xerces/ivy-2.5.0.xml
> Are these descriptors something that the Forrest
> project maintains, or do we copy them from somewhere
> else and thus need to keep them synchronised? I want
> to clean them up to be consistent w.r.t. license stuff
> etc. but not if they will come from some other project.
> It seems to me that it is better to keep our own descriptors.

The whole tools/ivy/repository section dir really go to an ivy community 
managed repo. The Ivy project has two, a scratchpad one where things may 
not be perfectly described in terms of their dependencies etc. and a 
main one where there are tight controls on what goes in there and so it 
should be complete and accurate (i.e. stable).

So, my intention is that whatever we end up with in our local repo will 
eventually be moved to the ivy scratchpad where the community can clean 
it up an eventually move it into the main ivy repo.

Why not do it straight into the ivy scratchpad? Because I want Forrest 
devs to see how the ivy files are put together so that there is a 
history in our archives for people to manage the scratchpad/main reop 
over in Ivy.

> Why xerces-2.5.0 when we currently use xerces-2.8.0?

I can only guess when I did the Forrest2 ivy repo I started it off by 
pulling the latest available from a Maven repo. So I ended up with 
xerces-2.5.0. I've not yet done the one in Forrest trunk so not yet 
upgraded to 2.8.0.

> Is your plan to move everything that we use out of lib/*
> into this local tools/ivy/repository, then gradually
> remove/tune stuff as we find them in other official repositories?

Yes, see above.

> I gather that we can have Ivy descriptors in our local
> repository, but no jars, and then point to other repositories
> for the jars, e.g. maven repo.

We don't even need the descriptors. We just need the ivy.xml file in our 
trunk. This tells Ivy what Forrest depends on. It goes off to the 
defined repositories (defined in tools/ivy/ivyconf.xml) and finds the 
relevant ivy.xml files for that dependency. This identifies any jars 
that are required by that dependency, which allows Ivy to go looking for 
them, and so on.

So, we are aiming at only needing to maintain Forrests ivy.xml file here 
in Forrest.


Here's the process I'm using at present:

1. remove a jar from the lib directory

2. add a dependency to the forrest ivy.xml file

3. try resolving the dependencies* - since the jar is not in our local 
repo it will go to the ivy and maven repos - it's supposed to go to the 
Cocoon repos too, but I haven't got that working yet. I joined the ivy 
user list to ask for advice but have not got around to it yet

4. if it resolves OK commit the changes, and go back to 1

5. if it fails to resolve we need to manually inspect the ivy repo to 
look to see if it is available with a different organisation or jar name 
(I don't bother doing this in the maven repos though

6. if it doesn't exist in the ivy repos then add the jar and ivy.xml to 
our tools/ivy/repository

7. try resolving dependencies, it should now work, so go back to 1.

* Note that I am using an Eclipse plugin to resolve the dependencies for 
me. Since you want to help I will make it a priority to create an ANT 
task to resolve them for us - I should be able to do this later today (GMT)


View raw message