ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: Open source ivy files project?
Date Wed, 16 Apr 2008 06:37:38 GMT
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].


[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


Mime
View raw message