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 14:05:59 GMT
Gav.... wrote:
>>> 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.
> I get the PMC responsibility bit, what I don't get is us updating files that
> Come from the ivyrep. I thought these are files that many projects make use
> Of. Or are you saying that 'one' of the projects that makes use of these
> Files will ensure they are compliant.

I'm saying that by the time we hand them off to Ivy they should be 
complete and useful files. Should we be the first to notice a future 
change with respect to licenses, version numbers or whatever, we should 
provide a patch to the Ivy team.

Just because it is not in our SVN does not mean we cannot continue to 
help maintain it.

Of course, the idea is that other projects use the same repo and conf 
files, thus we may find that some other project does updates before us. 
Then we have saved ourselves some time.

>> When building a binary release they will, of course, be copied into the
>> release. Ivy has tools for doing this.
> Ok, this answers my other post I guess, your intending to include all
> Jars as part of the release. So are we only utilising Ivy for our
> Own purposes / ease of use and not using it to ensure that when a 
> Release version gets downloaded by someone, Ivy could get the latest of
> Everything at the time. This would make for current release patches of
> Required files easier.

We are only using during the build process. A release should have a 
collection of libs that have been fully tested and, to the best of our 
knowledge work. Allowing Ivy to update dependencies in a release means 
that we have no longer tested that configuration.

>> 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.
> Ok, not sure how including the repo in the checkout makes things easier
> For devs, may as well have it set up how its supposed to be, this way
> Devs will get first hand usage of it straight away.

It may just be the way I am working locally. But I find it useful to 
have everything in a single checkout whilst I move things from one part 
of the tree to another. It makes the SVN commands considerably shorter 
an therefore less error prone.

Like I say, this may be a personal issue. I've set the config files up 
with a property to define the location of the shared ivy repo so it is 
really simple to move it once the migration is complete.

>>>>> 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.
> I'm now thinking along the lines of our Xalan issue and also in a way
> Cocoons upgrade to 2.1 could be an example. If we upgrade the public
> Repo version of xerces to 2.8 from 2.5 is there a possibility that
> We will break other peoples builds because of it?

No. That's the whole point of Ivy. You say what version you want, 2.5, 
2.8. 2.x. latest release, latest milestone or whatever. Ivy will get the 
  closest fit to the version you want (as well as trying to resolve 
conflicts in the dependency tree).

That is, the public repo can have version Xalan 2.5 and 2.8 at the same 
time. It is the local config that defines which one we retrieve. This is 
similar to, but more robust than, the plugin resolution mechanism we have.

>> 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)
> Ok, if not then we should do it?



View raw message