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.
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 <[EMAIL PROTECTED]> 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
