David, Dain, others,
I would like to volunteer for this.
Cheers
Prasad
On 11/9/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
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,
-dain
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:
>
> http://wiki.apache.org/geronimo/Maven2Conversion
>
> 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 <[EMAIL PROTECTED]> 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 ( 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
> >
>
>
