gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
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.

regards

Adam
----- Original Message ----- 
From: "Brett Porter" <bporter@f2network.com.au>
To: <gump@jakarta.apache.org>
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 ~ brett@apache.org
> blog: http://blogs.codehaus.org/people/brett
> Maven: http://maven.apache.org/
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message