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 Mon, 26 Feb 2007 09:41:53 GMT

> -----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.

I think the aim is that Ivy will update the license stuff in their
Public repo, they are now part of Apache and so I don't see why a
Transfer of license shouldn't take place. This would negate the
Need for us to update the license info I would have thought.
(Will check on that more thoroughly)

> 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.

Don't most jars/dependencies come from Ivy/ibiblio anyway ? During my
Limited time taking a look at Ivy over the last few days I understood
That required jars are downloaded if not already present, and look for
Updated versions and download them automatically if a new iteration

These jars would then be stored in our /lib/*/ directory.

Any 'Forrest' derived jars, are you intending that these get uploaded
To Ivy Scratchpad for approval and then moved to the main Ivy repo?

You mention 'local' repo, just thinking out loud here, my understanding
Of the 'local' repo was for testing/using in a localised environment such
As your computer, whereas using the 'Shared' repo would be a better fit
For Forrest as the Shared repo would be stored in our SVN. Even this, in 
The future may not be needed at all if Forrest specific dependencies were
Added to the Ivy public repo. That's my interpretation, could be wrong of

> > 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.

I guess this would be a prime example of using Forrests own Shared
Repo, if we don't like what version Ivy is sending us, we switch to 
Our repo for the version we do want.

> > 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 thought the idea was we use Ivy for our dependencies, Ivy manages
This and downloads the appropriate jars/versions - they would still
End up in the /lib/ directory , or not ? (They would come from either
Ivy Public repo or Forrest Shared Repo but still end up in /lib/)

> > 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.

And the ivyconf.xml

> ----
> 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

Hmm, I'm confused and not for the first time. I thought a repo holds all
Possible jars for all situations. I didn't think that is where you are 
Supposed to actually use them from. You use the ivy.xml to pull needed
Jars into /lib/ and use them from there. This is what I am assuming from
The Ivy Docs and downloaded tutorials.

I think you got an answer on the list.

Hope I'm helping not hindering, looks like the answer to many a prayer
Does Ivy so trying to understand it a little bit - as I can see we will
Be using it one way or another.


> 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