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 Mon, 26 Feb 2007 11:10:09 GMT
Gav.... wrote:
>> -----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
>>>>> 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)

No, the aim is for us to pass a set of conf files to the ivy scratchpad 
repository that work an are complete. It's our itch, we should scratch it.

Besides, it is our PMC's responsibility to ensure our licence 
information is valid.

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

Some do, whether it will be most remains to be seen. Certainly, some 
will not. Those that do not come from Ivy/Ibiblio need to be in our own 

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

Whether updates are downloaded automatically depends on our own ivy.xml. 
We can say "only version x.y.z", "any release", "any milestone release", 
"any minor version in the 1.2.y tree" etc.

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

They can be downloaded to a /lib/* directory, but there is little point 
in that.

You see ivy downloads all jars to a central cache on the hard disk, by 
default this is ~/.ivy/cache. All applications you have that use Ivy 
will use the jar from that location (i.e. only one version of each jar 
on your hard disk).

When building a binary release they will, of course, be copied into the 
release. Ivy has tools for doing this.

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

I'm not sure what you mean by "'Forrest' derived jars".

If you mean should binary releases of Forrest be in the ivy repo - then 
probably no, since the jars of Forrest1 are not really useful in an 
embedded environment. Forrest2 is a different story, but it is also far 
too early to b e worrying about that.

If you mean the snapshot builds of Cocoon we use, I doubt they will be 
useful in a public Ivy repo, so we will probably keep them in a Forrest 
managed 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
> Course.

You are right. A shared repo would make more sense, and that is exactly 
what we are moving towards. I've been mixing my terminology, by local I 
meant local to Forrest (i.e. what ivy calls a shared repo).

Right now the repo is in forrest/tools/ivy and is therefore checked out 
with Forrest svn checkout. This is a temporary thing. It makes it easier 
for other forrest devs to get involved with the migration to Ivy (a 
single checkout. However, you are right, we should, eventually, make 
this repo a completely separate SVN tree.

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

No, we update the public repo so that others get the benefit of our update.

Note in this case, since I have now made things work from the apache 
maven repo (rather than ibiblio) we should find the later version of 
xerces is available to us because someone else will have updated the 
apache maven repo (I would have thought)

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

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.
> And the ivyconf.xml


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

[ADDENDUM - I've fixed it now so it does go to the Apache Maven 
repositories, as used by Cocoon]

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

See above clarification regarding /lib/* - is it clearer now?

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

As ever, I am learning as we go so having to answer questions and 
justify any actions I am taking will highlight anything I have 
misunderstood from the Ivy docs. Keep it up!


View raw message