On Wed, Apr 16, 2008 at 8:37 AM, Gilles Scokart <[EMAIL PROTECTED]> 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 <[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] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
