Gump integration with Maven

[Brett Porter <bp...@f2network.com.au>]

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/

Re: Gump integration with Maven

[Stefan Bodewig <bo...@apache.org>]

On Wed, 12 May 2004, Brett Porter <bp...@f2network.com.au> wrote:

> I was finding myself a bit confused by the gump talk in context of
> Maven, especially with all the different spellings of artifact :)

In German it's Artefakt - hard to unlearn 8-)

> So, to sum up this point: I think gump should have just one id for a
> project,

What about projects that produce multiple jars?

> 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'm not sure whether I parse this correctly.  There will always be
projects that want to be built by Maven but depend on things that have
not been built by Maven.  So we'll have to make up some ids - or use
those that have been made up by others.

> 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.

Sounds interesting.

> 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.

<tongue-in-cheek>Aren't you going to release Maven and the plugins
rather soon?  Wouldn't you want your plugins to work with latest
Jelly?</tongue-in-cheek>

Seriously, since we are trying to get things working in the first
place, we may be better of with using a more conservative approach and
switch to the mode you propose here later - once we have a working
setup.

> 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.

Sounds OK to me.

Stefan

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

Re: Gump integration with Maven

["Adam R. B. Jack" <aj...@trysybase.com>]

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" <bp...@f2network.com.au>
To: <gu...@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