geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <>
Subject Re: m2: flushing out our dependencies
Date Wed, 09 Nov 2005 12:10:10 GMT
I have created the following wiki page from the unknown.txt file you checked

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. .


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