ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Open source ivy files project?
Date Wed, 16 Apr 2008 06:45:23 GMT
On Wed, Apr 16, 2008 at 8:37 AM, Gilles Scokart <gscokart@gmail.com> wrote:

> Maven has naming conventions [1], [2].
>
> The problem is that those conventions apeared  with maven 2.  maven 1
> didn't had this and the maven repository actully contains an export of
> the maven 1 repository.  That's why the naming convention didn't
> seemed to be always followed.
>
> Note however, that they give advices to fix that [3].

The problem is that the repository is cluttered with old naming conventions,
which make it sometimes difficult for users to find their way out:
http://javarepo.xoocode.org/search?q=%23hibernate%3B
http://javarepo.xoocode.org/search?q=%23commons-email%3B
http://javarepo.xoocode.org/search?q=%23commons-transaction%3B
http://javarepo.xoocode.org/search?q=%23commons-collections%3B

Xavier


>
>
>
> [1] http://maven.apache.org/guides/mini/guide-naming-conventions.html
> [2] http://maven.apache.org/maven-conventions.html
> [3] http://maven.apache.org/guides/mini/guide-relocation.html
>
>
> On 16/04/2008, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> > 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/
> >
>
>
> --
> Gilles Scokart
>
> ---------------------------------------------------------------------
> 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/

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