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 Wed, 16 Apr 2008 07:41:38 GMT
On Tue, Apr 15, 2008 at 5:22 PM, jonathan doklovic <jdoklovic@ibsys.com>
wrote:

> Interesting idea.
>
> I really think there is a need for a stable public repo as well as some
> standards for conf naming and such.
>
> I'm not sure I'm a fan of the build instructions though. It seems that
> pulling artifacts from the creators websites has some problems. Off the
> top of my head...  it could add a lot of time to resolve since a lot of
> OS sites are slow. (including sourceforge).  Also, as time goes by,
> sites have a tendency to archive artifacts and sometimes even remove
> them altogether, which would then in turn break the build instructions
> in either case.  Just seems like it might be more maintenance than it's
> worth.
>
> In my opinion, disk space is cheap and it would be more reliable to
> store copies of the artifacts in the public repo.


I agree with your arguments, but I do think storing build instructions is a
very good idea. By storing the build instructions, you get an easier import
of new versions from the project: let's say you have already written build
instructions for foo 1.1, when foo 1.2 is released, there is good chance
that your build instructions will only require minor adjustments. If
downloading, unzipping, repackaging sources and javadocs were done by hand,
you would have to reproduce the same steps each time.

Now I see this approach as an intermediary step: once you have a repository
with build instructions, it's super easy to setup a repository with actual
artifacts, built automatically from the build instructions. And if enough
people use the builder approach, I guess there will be enough interest to
get money to setup this repository.

That being said, I see a problem with hosting the repository in google code
svn repo: access seems to be very slow sometimes, and subversion doesn't
help. Maybe it would be interesting to have a public file server launching
an svn up in a cron? I have a small box which I use for xoocode.org hosting,
I could set this up if you think it's interesting.

Xavier

>
>
> Cool work though.
>
> - Jonathan
>
>
> On Tue, 2008-04-15 at 10:06 -0500, Archie Cobbs 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
> >
>



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