Hi, I was finding myself a bit confused by the gump talk in context of Maven, especially with all the different spellings of artifact :) I thought I should recount how I think they can work together in a way that meets gumps goals - let me know if I've got it wrong. I apologise for length.
Firstly, Maven's repository structure is setup to uniquely identify a particular dependency by a combination of group ID, artifact ID, type (JAR in all cases for gump I think, maybe extending to encompass plugin) and version. Formerly, groupID = artifactId and was called "id", and there is still a lot of evidence of that legacy in Maven projects. For now, I think that gump should concern itself with artifactId and not groupId. If there comes an occasion that two maven projects with two group Ids produce the same artifact Id, then we might need to look at alternatives to resolve the conflict. So, to sum up this point: I think gump should have just one id for a project, that being the artifact Id for now, and using the full Maven ID (groupId:artifactId:type) later when support and project usage is better. If this needes to be done alongside ant projects, I'll leave it up to the gump folk to decide how this is best treated. I imagine there shouldn't be clashes as projects will be either maven or ant, not both (while it might be possible, I imagine they only get gumped with one). Next, to building projects with maven inside gump, which is happening now. I think a build.properties file is being generated per project, and wanted to suggest the generation of an all encompassing jar override build.properties file in the user home directory. This will allow specifying the location of all JARs coming from gump, and will automatically apply to all maven built projects, including the maven plugins themselves. This should be much easier to maintain. The downside to this, is I imagine a bunch of Maven plugins will freak out at more recent versions of Jelly or other things, and this could hold up this part for a while to fix it. I think a fallback needs to be in place, and I'm not sure the best way to do this (copy the build.properties to all the projects being built, and remove it from the user home directory so that Maven itself is the only thing unaffected?) This is worth trying, as we might get further than expected, and certainly it appears gumps goal is to go down this path. The final item is gumping Maven itself. I've taken a look at building a new ant based bootstrap for this, and think it isn't necessary. Let me know if you agree. Based on the following. The current ant based bootstrap uses an ant task to do the first build of a maven core, using a set of known dependencies. It then uses this installation to build all the plugins, and finally it rebuilds maven completely using maven. At this last step, the jar overrides would kick in and maven would be completely built using a latest JAR maven. So while the whole process is not under gumps ideals, the end result is. Is this enough? I'd prefer not to have to modify this bootstrap for now. An alternative of course is to use a "known good" maven to build maven which we have goals for too. There is one stumbling block here: even if all the right JARs are put into $MAVEN_HOME/lib, forehead.conf hardcodes some filenames. Wildcards can be used, so this can easily be worked around if it becomes a problem. Let me know where to go next! Also, I seem to have lost the format for the <maven element in a gump descriptor, so if someone could send that through I'll implement that for the gump plugin soon. Cheers, Brett -- Brett Porter ~ [EMAIL PROTECTED] blog: http://blogs.codehaus.org/people/brett Maven: http://maven.apache.org/
