ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Ivy RoundUp Repository - feedback requested
Date Fri, 18 Apr 2008 16:56:21 GMT
On Fri, Apr 18, 2008 at 5:01 PM, Archie Cobbs <> wrote:

> On Thu, Apr 17, 2008 at 11:22 PM, Chris Hane <> wrote:
> > I think have a meta repository is a great step.  I have been following
> ivy
> > for a while.  I have on my todo list to replace (enhance) our project
> build
> > files to use Ivy.  However, I have been dragging my feet because I don't
> > want to build all of the ivy files that I will need.  I think having a
> > repository where ivy files can be shared is great - it's just icing that
> we
> > can have a plugin for ivy to do a lot of the repacking work.
> >
> Your experience sounds very similar to mine and is exactly what motivated
> this project in the first place...
> > I've noticed that you put up an initial list of ivy files.  Do you have
> a
> > process for adding more?  Submit patches to the issue tracker?
> >
> Right now I've just thrown a few modules in there as sort-of a
> proof-of-concept. Here's what I would like to happen next:
>   1. Get some additional contributors to join the Ivy RoundUp project.
>   I'm envisioning a fairly open project, meaning lots of "fine grained"
>   committers, or perhaps a small team of committers plus a larger pool of
>   "maintainers" who are assigned responsibility for each module. The goal
> here
>   is to allow people to focus on the modules they are interested in. This
> is
>   analogous to how FreeBSD's ports system works. The issue tracker is a
> good
>   vehicle for tracking requested additions and changes.
>   2. Decide what to do about the stuff in the maven2 repository. We have
>   the option here of building an automated tool that would "import"
> everything
>   in maven2, creating the ivy.xml equivalents of the POM, etc. for each
> module
>   on the fly. These ivy.xml files would form a starting point for further
>   refinements over time.
>   3. Flesh out the
> ModuleMaintainerGuidelines<
> on the collective wisdom on this list.
>   4. Establish a place for discussion and decision-making about module
>   naming, configurations, dependency mapping, etc. Add some new modules to
>   stimulate thinking.
> For #1, for now anybody who wants to join as a committer is welcome.. get
> in
> on the ground floor! :-)

I step up, even though I'm not sure to get much time to involve.

> For #2, this is an interesting discussion. I am willing to write the code,
> but I need the help of this list to understand what is the best approach.

Importing stuff from maven 2 is interesting because there's already a lot of
modules. But sometimes the quality is really not there, and the risk of a
massive import is to inherit the low level of quality. So I think we need to
be very careful with the import, and make import only when necessary at
least to start. A lot can be necessary pretty quickly (some projects bring a
lot of dependencies). IMO, what's very important to start having a good repo
is to have some tools to check the consistency. I think we need at least to
ensure that each module can be resolved alone with Ivy used with an empty
cache. This check is pretty easy to implement, and will save a lot of
mistakes. We could even put the xml resolution report in the repository: it
could be useful to have transitive dependencies information.

If we agree on package like naming convention for organization, another
interesting check is to check the organization name compared to the package
name (for java projects).

IMO implementing these checks is the most important to ensure a high level
of quality from the beginning. With these tools, it will be a lot safer to
provide commit rights to a large number of people. The problem is that
writing these tools require some time.


> For #3, I'd ask for anyone interested to add their thoughts and update the
> wiki.
> For #4, let's continue to use this mailing list for the time being. When
> the
> email traffic becomes more substantial we'll create a separate list.
> I'm looking forward to getting this up and running. I think it can become
> a
> great resource for all Ivy users.
> -Archie
> --
> Archie L. Cobbs

Xavier Hanin - Independent Java Consultant

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