geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: m2: flushing out our dependencies
Date Wed, 09 Nov 2005 17:09:31 GMT
After doing the conversion I know how much of a pain this is, and I  
just wanted to let you guys know I really appreciate the effort.

Thank you,


On Nov 9, 2005, at 4:10 AM, David H. DeWolf wrote:

> I have created the following wiki page from the unknown.txt file  
> you checked in:
> My hope is that it will help us track our progress and encourage  
> others to volunteer.  I'll start off by taking the jakarta commons  
> and pluto dependencies and making sure they are up to snuff.
> My suggestion to others is that if you are involved in a project  
> upon which geronimo depends - go ahead an volunteer to help out in  
> this process.  If many people take one or two projects which they  
> are allready familiar with and flush out the poms for them, it will  
> be much easier than one or two people contacting a slew of projects  
> they know practically nothing about. . .
> David
> On 11/9/05, David Blevins <> wrote:
> 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 (
> > 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/  Then I
> removed anything from the geronimo groupId as those would get built
> during an m2 build of geronimo.
>   svn co
> 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.
> 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
> >

View raw message