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 <[EMAIL PROTECTED]> wrote: > On Wed, Apr 9, 2008 at 9:14 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 8, 2008 at 4:07 PM, Xavier Hanin <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
