> maven integration might not be hacky (true, I had no idea we were > injectin stuff in, so I take that back) but it does not work at all.
Wanna take that back also? ;-) It works for a number of Maven projects. e.g. http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/index.html See: http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-id/gump_file/build.properties.html > Problem is > > http://brutus.apache.org/gump/public/excalibur/ > Basically, the first one I looked at either needed more Gump <depends in the descriptor (or changes to 'jar ids', see next) that lead to Maven jar overrides. BTW: The 'gump' goal for a Maven project takes this information from the POM and creates the correct Gump descriptor. Have you tried that? > Now, tell me, is this just a matter of fixing the excalibur.xml file or, > like Stephen suggested, the problem is much deeper? I'm on diaper duty today, so I haven't had chance to read Stephen's concerns. I also don't know if 'Magic' is involved here. That said, Stephen did mention groupId and artifactId -- whereas Gump has 'jar id' (which we map only to artifact id). As I understand it Maven 1.0 is still ok w/ artifact id, it isn't yet requiring groupId, that is coming soon. When it comes we'll probably use the module name as the groupId default, and allow overrides. The main problem we have is that Gump jar ids are not sufficiently unique, so we've decided to (bit by bit) change ours to match theirs. When I get time I'll look at these closer. regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
