> I was under the (wrong) expression that Gumpy would parse Maven's > project.xml instead of using a Gump descriptor and had difficulties to > map the project names.
No, Gump has enough complex code for loading metadata, I'd really rather rely upon the gump goal in maven & not introduce yet another XML element called "<project" (of a different flavour.) Also, we need to make more progress on seeing <maven builds (so I appreciate you brining this up) before we invest more around the edges. > > As I see it, the main issue is artefact ids for projects that Gump > > builds (likely using ant) that do not have a Maven equivalent build, > > so perhaps not 'artefact id' in Maven. > > Any idea how the Maven Gump plugin deals with it? I'd assume it will > simply make the project depend on the pther project without specifying > any ids - and thus get all the jars. Actually, no idea. :( Reading: http://maven.apache.org/reference/project-descriptor.html#dependencies http://maven.apache.org/reference/project-descriptor.html#dependency I suspect that groupId, artifactId,jar,type all play a role (and I see that 'id' is deprecated.) From these I can see that the 'gump' maven goal can generate dependencies (groupId = Gump project) and ids. Hopefully POM project descriptors specify all groupIds and artifactIds, otherwise Gump can't use set the classpath overrides. > But you need an id to specify the jat name override, right? Correct. > If this is a the problem, then we'll need Brett's help, I assume. A Mavenite's insights would certainly help. > How does the repository effort address this? Does it address this at > all? I think it does, but as a side effect. I think we (Apache/others) just come to a consensus on group and artefact ids. I suspect we are far closer to condenses than we realize, and we should just (all) work towards a common set. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
