ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs" <>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Thu, 17 Apr 2008 14:31:23 GMT
Thanks for your feedback!

On Thu, Apr 17, 2008 at 4:40 AM, Gilles Scokart <> wrote:

> 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

Yes, this is easy to achieve during the repository build process. We also do
XSD checks, etc.

> 2. As I said before, I don't like the term 'build'.  Something like
> 'download', 'install', 'get', etc... would be much better.

My apologies about the naming... I didn't realize that there was so much

When I started implementing this resolver, I tried to think about "building"
as broadly as possible. Then later, for security reasons (and because
get/unzip/etc. is all that's really needed), it seemed better to limit what
the "build" process can do to simply extracting files and/or repackaging
them. So really now it perhaps should be called the "extractor" resolver or

In any case, because it uses ant to "build" the artifacts, in theory any
more general "build" process is possible. For example, occasionally I've
seen someone publish a small, one-class Java utility simply putting the
source file up on the web somewhere. To use this, it has to be compiled and
packaged into a jar manually. A more general "builder" resolver could do
this for you.

Those oddball cases are rare, so I'm happy for now restricting the "builder"
to just being an "extractor" or whatever. But in general, there may be cases
where more a general "building" capability is needed.

There could also be configuration knobs to allow this, e.g.,
allowGeneralBuild="true" or somesuch. Also digital signatures would help
make this safer.

> 3. Signatures should be considered, and all meta-data files should be
> signed.

Yes this idea was mentioned before and certainly makes sense.

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

This will happen naturally, and follow the trunk, branches, and tags in SVN.
E.g. we may release and tag "Ivy RoundUp 1.0.3", which will persist
indefintely at an unique URL. Any user who points to that URL will always
get the same thing. When the user wants to "upgrade", they change their URL
to point to a newer release (or branch, if they want continuous updates).

> 5. A dependency repository needs to :
>                        - Notify users in case of a new version of a module
> that he use.
>                        - Provides release notes links.

Yes, this could follow the conventions of any project: mailing list, "News"
page, etc. Each release would have release notes. All very standard...

> 6. You might encounter hosting issues

Not sure what you mean here...


Archie L. Cobbs

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