Brett wrote:
> > Seems the problem of 'jar id' != 'artifact id', i.e. where Gump and Maven > > don't have a shared view of the names of these things. Recall, Gump had > > 'context sensetive' jar ids (within the context of that project) it did not > > have unique ones, like Maven does/requires. > > I don't quite understand here... what gump ID does ant-junit have > compared to junit that they ended up the same in Maven? Unfortunately it has "junit", the reason being was that Gump 'jar ids' were within the scope of the project, so the 'ant' was implied. Since Gump only has 'jar id' that is the only thing that Gump can pass to Maven. Hence we need to make Gump 'jar ids' globally unique, and (for want of a better) match Maven 'artifact ids'. > JAR overrides do have a limitation in that they currently don't really > support the Maven id structure of group:artifact, which is planned to > be fixed for 1.1. If you have time to explain in more detail I'd appreciate that, I'm not quite following. > > Shorter term, I say we look at making the Gump ids closer to unique ids > > (and/or equal to those in Maven). Agreed. > There's nothing particularly special about the maven ones, so a > group:artifact structure should be reasonable to match. > > > In Ant's Gump descriptor, these problably ought change: > > I'm curious how they got there in the first place. I understand that > you are traversing the dependency tree, but if you are building with > Maven, why is there a dependency on ant-1.6 in there? I assume this is > because of the magic dependency in there? No clue. I agree, not sure why they are there. > It just seems that a couple of things are being mixed together in > here, which doesn't seem quite right. > > > So 1 to not quite 1. ;-) Any problem if we add it for "correctness" of Gump > > metadata? > > No, but I would argue with your definition of "correctness" :) I don't > think a build should be offered up several dependencies it hasn't > asked to use. I agree. I was saying "correct" because I thought it used "junit", so I feel it ought ask for it (not have Maven transparently add it). > If, for Maven builds, build.properties matched the dependencies in > project.xml for each directory - nothing more, nothing less - then the > project can determine it's own fate in terms of clashes. Agreed, and if they used your gump plug-in to make the Gump descriptor they would. > This does mean some JARs used by plugins such as junit will not be > overriden here. The solution to this that each plugin in the maven > installation also needs a build.properties file to accompany its > project.xml. Or we build Maven from scratch using Gump'ed artifacts? > That said, this would be simpler if all clashes could be avoided by > making gump id's unique and 1:1 with Maven id's, because with that > guarantee you could simply declare all ID's in ~/build.properties (a > global override) and not have to modify every project. I agree, make them match. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
