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: domain of xavier.hanin@gmail.com
 designates 72.14.204.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=SpZtjUqxl2TrFOg67HWF9x6X/OBHjPua1MpXQR7t98Ug2zChsF+HcmiMdcKRuiRVO52cvIE718iV1WZZitIqCWK+8Fxx5Kx4aFobCblDNNDlrE9u6bOTcPJgn2iKnZ4v8YKS6Si1YI05hCrDoofm3HDdNZCyBaLa1hVgi8x03Kk=
Message-ID: <635a05060804181006x39f57476v84d93bdc67b892f3@mail.gmail.com>
Date: Fri, 18 Apr 2008 19:06:40 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@ant.apache.org
Subject: Re: Ivy RoundUp Repository - feedback requested
In-Reply-To: <635a05060804180956k615d7270w344dec2dfbe70428@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9422_14697743.1208538400939"
References: <3bc8237c0804150806j41812cdfv9938be9f1da0adce@mail.gmail.com>
	 <4808221E.6020203@gmail.com>
	 <3bc8237c0804180801x1e784510gde8dd559a332db32@mail.gmail.com>
	 <635a05060804180956k615d7270w344dec2dfbe70428@mail.gmail.com>

------=_Part_9422_14697743.1208538400939
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Fri, Apr 18, 2008 at 6:56 PM, Xavier Hanin <xavier.hanin@gmail.com>
wrote:

> On Fri, Apr 18, 2008 at 5:01 PM, Archie Cobbs <archie@dellroad.org> wrote:
>
> > On Thu, Apr 17, 2008 at 11:22 PM, Chris Hane <chrishane@gmail.com>
> > 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<
> > http://code.google.com/p/ivyroundup/wiki/ModuleMaintainerGuidelines
> > >based
> > 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.
>
Speaking about tooling, some of you may be aware sometime ago I participated
to a project called worldofjava, which is now dead... This project provided
access to source and javadocs of a large number of projects. For those that
were not available in maven repo, or without sources or javadocs, we built a
tool which was able to scan some web sites to find new versions
(sourceforge, ASF, objectweb, ...), download the archives, analyze the
content and try find interesting bits in the archive. This analysis
generates a descriptor (pretty much like your build, but more descriptor
oriented than task oriented) that we edited manually when the automatic
analysis was not good enough.

I'm speaking about this because the code is now open source (meaning only
that anyone can reuse it, there's no community behind). So it might be
interesting to reuse some parts of this tool. Here's the source of the
analyzer:
http://woj.svn.sourceforge.net/viewvc/woj/woj-tools/src/java/org/jayasoft/woj/tools/analyzer/DLAnalyzer.java?revision=17&view=markup

BTW, jayasoft is still the owner of the repository used by WOJ, and I'm the
co owner of Jayasoft, so I can discuss with the other owner to see if we can
open source the repository too. It doesn't contain any Ivy files (maybe one
or two), but it already contains a lot of cleanly extracted sources,
javadocs, artifacts, and descriptors to extract them from the original
archives. Don't know if you think it would be interesting...

Xavier


>
>
> Xavier
>
>
> >
> > 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
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

------=_Part_9422_14697743.1208538400939--