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?
yes.
Ross
