On Thu, Apr 17, 2008 at 1:10 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> It depends how you consider the roundup repository. I think its intent is > to > be a kind of meta repository: it contains metadata helping to build an > actual repository. Maybe what's confusing is that archie suggest to use it > as a repository directly. IMO this is required only until we can get > enough > support to have a good hosting for the actual repository. Then both the > meta > repository and the actual repository would make sense: the meta repository > is helpful for people who want to create their own repository, and easier > to > update than a repository made by hand. But it isn't used directly from > Ivy. > The actual repository is the only thing that is used by mere users. > There are actually three possibilities... 1. Builder Repository: repository contains ivy.xml and builder.xml files only, and the user is required to use the builder resolver, whereby the actual artifacts are downloaded and extracted as necessary at resolution time. 2. Builder Repository + Artifact repository: same as above, but you configure your resolver with the "resourceURL" attribute (which overrides the normal resource URLs), which points to the Artifact repository containing all of the ZIP/TGZ files that you need to download. The Artifact repository could be local or community/online. This means we don't have to rely on each/every project's server being reliable. 3. Build-your-own-Repository: we would add a new ant task in the Ivy RoundUp build.xml that actually executes all the builder.xml download/extract instructions for every module in the repository to get all the artifacts and then combines those artifacts with the ivy.xml files to create a normal Ivy repository. Correlating with Xavier's comments: #3 == "meta repository" whereas #1 = "repository directly". The important concept here is *separation of the meta-data from the data*. Also important is *not forcing the requirement for a high capacity, high bandwidth public server*.... I'll repeat my claim that this is important based on the evidence that nobody has yet volunteered to replace Ivyrep. If someone is willing to host a normal repository, then options #2 or #3 make sense. If not, then #1 makes sense. But it is flexible enough to work in any/all of these ways. I think we should start with #1 and then we can move to #2 or #3 if and when someone volunteers the additional servers and disk space. -Archie -- Archie L. Cobbs
