ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Fri, 18 Apr 2008 10:15:32 GMT
On Thu, Apr 17, 2008 at 8:59 PM, Archie Cobbs <archie@dellroad.org> wrote:

> On Thu, Apr 17, 2008 at 1:10 PM, Xavier Hanin <xavier.hanin@gmail.com>
> 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.

+1. Starting with #1 is the best option right now, then we'll later move to
either #2 or #3 (I prefer #3, but it's only my opinion).

Xavier

>
>
> -Archie
>
> --
> Archie L. Cobbs
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message