Mailing-List: contact ivy-user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@ant.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=HH7aOI+LHhsClK0qPbvPyfFoB3dcZfEg8WEa1pbHGLNTBYItJ8TNHDfI+3G1td4orFWOI/NszKr8SEn3NkcHtaev0f+Qv1PZibvDoncSIjNdLcLV63QnnVCJnp6JdLxgBEiP/1BfHKuEMj8bpHZE5oeV+gFywRD8PZNKKtN4hHY=;
Date: Thu, 17 Apr 2008 07:25:59 -0700 (PDT)
From: Matt Benson <gudnabrsam@yahoo.com>
Subject: Re: Ivy RoundUp Repository - feedback requested
To: ivy-user@ant.apache.org
In-Reply-To: <e9d8a2610804170240ra8d435w4e4f15c97f4257a0@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <353017.43499.qm@web55108.mail.re4.yahoo.com>


--- Gilles Scokart <gscokart@gmail.com> wrote:

> A few more feed back:
> 
> 1. I like the fact that the ivy.xml and build.xml
> contains a license
> boilerplate.  I think it should a rule, and that the
> AL should be
> applied systematically for all meta-data info stored
> in ivy-rep
> 2. As I said before, I don't like the term 'build'. 
> Something like
> 'download', 'install', 'get', etc... would be much
> better.

To chime in here, I'd like to point out that in some
extreme hypothetical case a project might release in
source form only.  In this case a build _would_ take
place.  I'd like to see the RoundUp concept be
reusable within an organization, where the build/get
instructions might be to pull a particular svn tag,
then execute an Ant build.  So maybe "build" assumes
too much, but we could explore some middleground that
simply implies that some processing must take place...
"prepare"?

-Matt


> 3. Signatures should be considered, and all
> meta-data files should be signed.
> 4. You should consider versioning of the meta-data. 
>  ivyroundup will
> be a downstream distributor, you can make errors
> that you will have to
> fix, without asking a new release from your upstream
> distributor, and
> still allowing build reproduceability.
> (by build reproduceability, I mean that the user
> must be able to
> define with high precision what he want to change).
> 5. A dependency repository needs to :
> 			- Notify users in case of a new version of a
> module that he use.
> 			- Provides release notes links.
> 6. You might encounter hosting issues
> 
> 
> On 15/04/2008, Archie Cobbs <archie@dellroad.org>
> wrote:
> > Hello fellow Ivy users,
> >
> >  I'd like to announce a new little project I've
> started, and ask for your
> >  feedback (and help, if interested).
> >
> >  This project has two basic parts...
> >
> >    1. *Builder
>
Resolver*<http://ivyroundup.googlecode.com/svn/wiki/files/builder.html>:
> >    a new Ivy resolver that accesses ivy files and
> "build instructions" from an
> >    online "builder" repository. "Builder"
> repositories contain ivy.xml files
> >    but no artifacts. To get the artifacts, the
> build instructions are
> >    downloaded from the repository and executed
> locally. These instructions
> >    specify additional resource(s) to download and
> how to build the artifacts
> >    from them, for example, by downloading a
> project's original distribution
> >    archive directly from their web site and
> extracting the desired artifacts.
> >    2. *Ivy RoundUp Repository*
> <http://ivyroundup.googlecode.com/>: an
> >    online, open-source community "Builder"
> repository for all Ivy users.
> >
> >  Please click the links for more info and
> documentation.
> >
> >  I am lobbying to get the builder resolver added
> into Ivy itself; right now
> >  it's still in patch form (you can download a
> pre-built ivy.jar from the
> >  project website).
> >
> >  Some motivations for starting this project:
> >
> >    1. Ivyrep is no longer maintained, but we need
> a decent community Ivy
> >    repository that everyone can share
> >    2. Hosting hundreds of large files that are
> just copies of the same
> >    files available elsewhere is expensive and
> redundant, so let's avoid doing
> >    that
> >    3. 99% of projects out there do not publish
> ivy.xml files, so we need
> >    a community project that focuses on developing
> and maintaining them
> >    4. To get the most out of Ivy, there needs to
> be a consistent set of
> >    guidelines for creating ivy.xml files: how to
> choose organization names,
> >    philosophy for defining configurations, etc. A
> community project supported
> >    by Ivy users can provide this.
> >
> >  What I want to do is gauge interest in this idea
> and ask for any volunteers
> >  who'd like to start adding and maintaining
> meta-data for their favorite
> >  projects. The Ivy RoundUp repository is online
> now, though only as a
> >  proof-of-concept (it only contains a few modules
> so far). Take a look and
> >  you should be able to get the general idea:
> >  http://ivyroundup.googlecode.com/
> >
> >  In the worst case, if nobody else is interested,
> I will just use this for
> >  myself -- it's already working better than what I
> was doing (i.e., checking
> >  in giant ZIP files into Subversion and creating a
> project for every one to
> >  publish into our private Ivy repository), and in
> any case the work of
> >  setting it up is already done. Note also anyone
> could create their own
> >  private builder repository using this project as
> well.
> >
> >  In the best case, we'll put together a piece of
> infrastructure that all Ivy
> >  users can really benefit from.
> >
> >  Let me know what you think.
> >
> >  Thanks,
> >  -Archie
> >
> >
> >  --
> >  Archie L. Cobbs
> >
> 
> 
> -- 
> Gilles Scokart
> 


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ