Gav.... wrote:
-----Original Message-----
From: Ross Gardler [mailto:[EMAIL PROTECTED]
Sent: Thursday, 22 February 2007 7:30 PM
To: [email protected]
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)
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
repo.
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
Yes.
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!
Ross
