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/
