gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: Gump integration with Maven
Date Wed, 12 May 2004 04:56:17 GMT
Thanks Brett. I'm in the office (work work) tomorrow, but will dig into this
when I next can. Questions will likely follow.


----- Original Message ----- 
From: "Brett Porter" <>
To: <>
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
> 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
> 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
> possible, I imagine they only get gumped with one).
> Next, to building projects with maven inside gump, which is happening now.
> think a file is being generated per project, and wanted
> suggest the generation of an all encompassing jar override
> file in the user home directory. This will allow specifying the location
> all JARs coming from gump, and will automatically apply to all maven built
> projects, including the maven plugins themselves. This should be much
> 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 to all
> the projects being built, and remove it from the user home directory so
> 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
> 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
> 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
> 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 ~
> blog:
> Maven:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message