> I think you're spot on that gump basically needs to change to support the > maven model of one-jar-per-project-definition.
great! > In fact making it > one-output-per-project-definition seems to make even more sense, where a > "maven dist" is a different project from a "maven jar". I'm not so sure about this. Which parts of the definition actually change other than the outputs part? > It will take a while for us to get there. One thing I wouldn't like to see > happening is that you need 20 project definitions for a single ant command > that results in 20 jars. I.e. Gump needs to support maven's > one-jar-per-project model, but also others, and they all need to be > convenient to set up. Right - my solution proposed in there covers that. The JAR ID concept would continue to work by modifying the artifact ID of the several outputs: eg: <jar name="dist/asm.jar" artifactId="asm" /> <jar name="dist/asm-util.jar" artifactId="asm-util" /> This is very close to what is already there, and in several cases the same. However, these are effectively being promoted to the level of projects now. Therefore, id/ids would be removed from <depend/>. > Thinking about just doing (module = groupid, project = artifactid), that > might get us into problems as the module name is also used for other things > at the moment. But IIRC you can override that behaviour, so let's make that > happen! Yes, everything I saw module being used for was as a path and was configurable elsewhere. As far as I can tell, this gives a few simple steps forward to the correct solution. For the long term goal, I agree with Stefano and yourself - to be able to read the Maven project descriptor directly and have gump understand it. As is shown by the Maven gump plugin, everything in the gump descriptor can be derived from that presently. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
