forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <>
Subject RE: [PROPOSAL] Switch dependency managment to IVY
Date Thu, 22 Feb 2007 12:22:31 GMT
Below is some great information, I am beginning to understand
This better now, so thanks for this, very useful. Can it be
Doc'ed anywhere do you think as is or do you think the docs
You have done say the same thing ? (Either way this says it
Better IMHO)



> -----Original Message-----
> From: Ross Gardler []
> Sent: Thursday, 22 February 2007 7:30 PM
> To:
> Subject: Re: [PROPOSAL] Switch dependency managment to IVY
> 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)
> Ross
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.412 / Virus Database: 268.18.2/692 - Release Date: 2/18/2007

View raw message