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]


Reply via email to