Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: domain of xavier.hanin@gmail.com
 designates 209.85.200.168 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=FX5evmvpfgKVAHeIhNhJHNOceRQXsSkonRsg0z6hVGIeO6K7E4WcHTFjB/3NJGxdnooDk950uhdTUvqWPrwpDM8zwXxXkvnanS9M78dh9bZrW6nvICZMvTXCewg99v6m+nwY+ofZuS56xRNVF7pldjgLWrzExqLAIy6WOU+1jk4=
Message-ID: <635a05060804152324q75db3836u216defe1d3db4eb2@mail.gmail.com>
Date: Wed, 16 Apr 2008 08:24:23 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: "Ant Developers List" <dev@ant.apache.org>
Subject: Re: Open source ivy files project?
In-Reply-To: <3bc8237c0804091214x76e57485n6c62a57175e9c39@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_59863_4270816.1208327063796"
References: <3bc8237c0804011548t6e9f3359od97cce162e83dd53@mail.gmail.com>
	 <3bc8237c0804042005x65eb0e3epe467330e1962eee8@mail.gmail.com>
	 <635a05060804070056p79c1d16ofb527f6837db5f46@mail.gmail.com>
	 <3bc8237c0804070756r43ba5017wc01a18764b4f4f4c@mail.gmail.com>
	 <635a05060804070831p7c83148ftefdf84768629a8e2@mail.gmail.com>
	 <3bc8237c0804071235x24614f86g48fc446c223968de@mail.gmail.com>
	 <635a05060804080016k78801ee8pdb0bf6eb907e3d7b@mail.gmail.com>
	 <3bc8237c0804080920o2a512320ub3e86d5f86a1d5b0@mail.gmail.com>
	 <635a05060804081407i45b5faf2j4c6693735fac129d@mail.gmail.com>
	 <3bc8237c0804091214x76e57485n6c62a57175e9c39@mail.gmail.com>

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

On Wed, Apr 9, 2008 at 9:14 PM, Archie Cobbs <archie@dellroad.org> wrote:

> On Tue, Apr 8, 2008 at 4:07 PM, Xavier Hanin <xavier.hanin@gmail.com>
> wrote:
>
> > > I agree completely and this should be very easy to do... unfortunately
> > I
> > > have zero knowledge of maven. I do have lots of knowledge of XSLT
> > though
> > > so if someone could walk me through what steps need to be done for a
> > > <m2resource> tag then I'll be happy to write it up in the XSLT.
> >
> > If it's only to download artifacts, it's very easy. All you need is to
> > download the artifacts using a pattern like this:
> >
> > [organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
> >
> > The classifier needs to be provided in the m2resource tag, except for
> > the
> > main artifact, which has no classifier.
> >
> > For instance here are the files available for Ivy itself on maven repo:
> > http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.0.0-beta2/
> >
> > As you can see there's the default artifact (the jar), an artifact for
> > 'sources' classifier, and one for 'javadoc' classifier. Maybe we should
> > also
> > be able to specify the ext for each artifact, and also the file path to
> > use
> > once downloaded (relative to artifacts dir). Maybe something like:
> > <m2resource groupId="org.apache.ivy" artifactId="ivy"
> > version="2.0.0-beta2">
> >  <artifact ext="jar" tofile="jars/ivy.jar"
> > sha1="43188890f8eb2a105665d62c4bda4b24703568ee" />
> >  <artifact qualifier="sources" ext="jar" tofile="sources/ivy.zip"
> > sha1="6ab99abd8a02a961a5054b0359b9ae75f2ae2972" />
> >  <artifact qualifier="javadoc" ext="jar" tofile="javadocs/javadoc.zip"
> > sha1="6b3cf2877a1c79adb181fa218b99f3b20ceabbe5" />
> > </m2resource>
> >
> > Not sure of the exact syntax, but you get the idea.
> >
>
> OK I think this should be easy to do... see updated patch (attached) which
> includes <m2resource>, ivy documentation, and new schema validation.
>
I've quickly reviewed the patch, and it seems to be exactly what I was
thinking.

>
>
> This does bring up a larger question I want to ask first: are we sure we
> really want to create and maintain an ivy module in ivyroundup for every
> package in the maven2 repository?
>
> Obviously, ivy is better than maven :-) but what happens if we don't?
> Someone could always just configure one builder resolver to point at
> ivyroundup and the other ibiblio resovler at the maven2 repo.
>

If people do this, we will probably end up with one of the problems of maven
2 repo: inconsistent names. If people need to use ivyroundup with maven2,
they will probably create dependencies in roundup to maven2 repo, and so you
quickly get inconsistent names. I believe to have something clean we need
both tools to ease the import of modules from maven2 repo to ivy roundup AND
community check of the quality of what is imported.


>
> But let's assume we do want to do this. For this to be feasible, we need
> to ensure the maintenance of all these modules is not a huge burden, and
> that they add some kind of value.
>
> A definite requirement would a custom ant task in the ivyroundup project
> that automatically populates the ivyroundup repository with all the maven2
> projects by downloading every pom and meta-data file from the maven2 repo
> and processing them automatically.
>
For many cases, this is fine. But as I said, if we don't want to replaicate
the same problems as the maven2 repo, we can't do things that automatically:
we need human or community checks of what is imported. For some modules,
when we know creators provide good metadata, we could fully automate the
import of new versions. In other cases, we'd need to change the organization
or module name, and keep the rest. In worst cases, only the jar could be
reusable, while we'd still need to find sources and javadocs ourselves. This
is quite a huge work, and as such require a community of motivated people.


>
> I'm willing to write this but I'd need some help/advice on what exactly to
> do since I'm still learning about maven.
>
You don't have much to know to do this: Ivy is already able to convert poms
to ivy files. So the main requirement is to understand that groupId is
organization in Ivy, and artifactId is module name in Ivy. Then there is the
conversion of dots in slashes in the repository for groupId, and the concept
of qualifier, which is mainly used for javadoc and sources, and which is not
stored in metadata: you have no way to know which qualified artifacts are
available except by listing files in the module revision directory.

>
>
> Once this is done, over time people can go through and improve/refine the
> auto-generated ivy.xml files... assuming we have some volunteers who are
> interested in specific projects, etc.
>
I think we at least need to avoid having the same inconsistencies in names
from the beginning. Having clear rules for module names and orgs (like
following the package name convention) is the only way to avoid the problems
you have when you search the maven repo for a module and end up with what
seem to be the good answer with different organizations, and different
versions. If we mimic maven2 repo, I see no added value. Obviously, doing
this kind of work takes time...

>
>
> Does that make sense?
>
> In any case, I've populated the Ivy RoundUp web site with a few modules,
> including one maven2 one (commons-email). Please take a look and let me know
> if it looks reasonable to you so far.
>
I'm already quite lost with the modules, which demonstrate the need to clean
the names before doing the import. I see commons modules in their own
organization (exactly as in maven2 repo) and commons-email in
org.apache.commons organization (which makes better sense to me). This once
again shows the difficulty to do something really better than maven2 repo.

Xavier


>
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>


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

------=_Part_59863_4270816.1208327063796--