Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of david.blevins@visi.com
 designates 208.42.156.9 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <43716B9D.4080900@apache.org>
References: <8F117A98-94BA-49D6-83CE-7C6763534BC8@visi.com>
 <43716B9D.4080900@apache.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AD093D77-7CAE-4B93-A6E7-D40186A21ECD@visi.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: m2: flushing out our dependencies
Date: Tue, 8 Nov 2005 21:08:48 -0800
To: dev@geronimo.apache.org


On Nov 8, 2005, at 7:23 PM, David H. DeWolf wrote:

> Sure.  I'm willing to help out.
>
> To start with can you provide a breif intro to your progress so  
> far. I've taken a look at gbuild in svn (http://svn.apache.org/ 
> repos/asf/geronimo/gbuild/) and don't see a pom or any traces of m2  
> migration. I've also looked and can't find any branches.

Added.  But really, it's the main Geronimo deps I'm worried about.   
This was just the eye-opener, for me anyway.

> It appears as though there is a pom in the trunk. Is that also  
> considered gbuild?  Sorry for my ignorance!
>

No problem.  To give the idea a little structure, I created a  
directory called m2assembly and added in all the dependencies from  
our geronimo/trunk/modules/assembly/project.xml.  I used the magic  
bash/perl goo I posted last week to replace all the ${foo_version}  
entries with the actual versions from etc/project.properties.  Then I  
removed anything from the geronimo groupId as those would get built  
during an m2 build of geronimo.

  svn co https://svn.apache.org/repos/asf/geronimo/gbuild/m2assembly

So that little project contains all our known dependencies more or  
less.  There are 100 of them to plow through, possibly some  
duplicates and maybe a few we don't need anymore.  There is no code  
in the m2assembly project to speak of, but it's more than enough to  
start the process of hunting down and patching/creating poms for the  
things we need.

I added these files:
   m2assembly/bad.txt
   m2assembly/unkown.txt
   m2assembly/missing.txt

...which I'm hoping we can use to put a little order on the effort so  
this can be a multi-person job.  I put everything from the pom.xml  
into the unkown.txt file for now.  We can delete what's good (or make  
a good.txt file) and move stuff into missing.txt and bad.txt.  I put  
everything in the format of 'groupId:artifactId:version'.  JIRA might  
be something to consider once we are further along.

If you come up with ideas on how to tackle all this, great!  Just  
kind of throwing this together ad-hoc.  Feel free to get creative.

This little guide describes how to fix, add, improve the metadata  
(poms) in the ibiblio maven2 repo.

   http://maven.apache.org/guides/mini/guide-maven-evangelism.html

Thanks for volunteering David!

-David


> Thanks,
>
> David
>
> David Blevins wrote:
>> So it's become pretty clear to me after trying to use m2 in  
>> gbuild  with a dependency on activemq that we have quite a lot of  
>> work ahead  of us flushing out valid pom.xml files for all our  
>> dependencies and  our dependency's dependencies.  I had always  
>> assumed the largest  barrier to entry on m2 was the plugins, but  
>> the dependency-war is  proving to be a huge battle.
>> At first blush, it's clear we have dependencies that aren't in the  
>> m2  repo and dependencies that are in the repo but with bad  
>> pom.xml  files.  It's going to be a lot of work to get a list of  
>> what needs to  be taken care of in regards to dependencies (what's  
>> missing, what's  bad) and even more work to fix each one and it's  
>> downstream  dependencies.
>> I personally don't have time to deal with it, but am posting as  
>> it's  a huge issue we should be looking at and am really hoping  
>> some people  (committer or not) will pop up and volunteer to help.
>> Again, there is little advantage to being a Geronimo committer  
>> for  this task as the bulk of the work is flushing out  
>> dependencies which  are all external by nature.  A sense of  
>> adventure, spare time, and  willingness to go knock on the doors  
>> of other projects on behalf of  Geronimo is all you need.
>> Any volunteers?  The more the better.  It'd be nice if someone  
>> could  put together a list and divide the work up.
>> -David
>