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 13:24:08 GMT

> -----Original Message-----
> From: Ross Gardler []
> Sent: Monday, 26 February 2007 8:10 PM
> To:
> Subject: Re: [PROPOSAL] Switch dependency managment to IVY
> 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
> 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.

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.

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

Ok, yep got that.

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

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

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.

> >>> 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? Then again, Ivyrep
Would never get updated if everyone thought like that (!?!) - I
Suppose it would be up to the other projects to ensure they're Ivy was
Configured correctly and so would not download it until they are 

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

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

Yep, much, thanks.


> > 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
> --
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.1.412 / Virus Database: 268.18.2/692 - Release Date: 2/18/2007

View raw message