argh, what a can of worms I have opened :) It seems like using maven 2 in the gump descriptor is unsupported and sort of defeats the purpose, so I don't think that's a good idea. It does strike me a little silly to make metadata for a testing library, but it's not some onerous task that will block me for weeks. And it'll be a decent learning experience.
I'll email the gump devs for some help; I think I can set up the descriptor myself, but I bet retroweaver is going to cause some grief. On 6/15/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
AIUI the purpose of gump is to give advance warning of upcoming problems by building from the latest source. So if there were changes in the smtp/wiser project that affected Commons email, you get advance warning. Since as you say, its only a test dependency then its probably not as important. From a practical PoV if you just want to use a "packaged" dependency in gump - rather than building those jars from source then (from my past experience of gump) you need the help of the gump devs - anyone can change the gump metadata - but adding a packaged jar requires privs. that ordinary ASF committers don't have on gump. Having said that, from what Bill said in this thread, if you switch gump to use maven2 then thats effectively what you get (for all dependencies). Doing that though seems to me to loose all gump benefits for Commons Email though - so it would be there (i.e. in gump) only to benefit downstream dependencies. So I think either you fix it yourself by either switching to maven2 or setting up subethasmtp project on gump to build from source. Or you ask the gump devs to help - and let them solve it in the way they think best. Niall --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]