Thanks Brett. I'm in the office (work work) tomorrow, but will dig into this when I next can. Questions will likely follow.
regards Adam ----- Original Message ----- From: "Brett Porter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 11, 2004 9:51 PM Subject: Gump integration with Maven > 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/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
