gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Maven 2 (was Re: Maven 1.1)
Date Wed, 16 Nov 2005 05:45:56 GMT
Ok, here's the opportunity for me to write the mail in my head.

Aside from the non-existance of a gump machine right now, what is
needed to use Maven 2,
a) minimally
b) ideally

Because it has an even more online nature (plugins are not
preinstalled), to use an installed version we'd again need to create a
minimal local repository including those plugins, then use offline
mode (-o), and ensure it can't get any internet access just to make

However, it should be pretty easy to step it up to the next level.
Instead of a pre-installed repository, we can add a "Gump artifact

What I'd need to know is the best way to make that work. Can you
verify that to resolve a JAR file in gump (assuming gump has already
built it) I'd need to:
* know the base working directory
* know the location of the gump XML file
* parse out <project name> and within that <jar name>
* look in base/project_name/jar_name

The resolver can also parse these files for depends. This would
require knowing where everything is, so even better would be:
* a list of directories creating gump descriptors
* that all files in the descriptor are relative to that gump descriptor

Is that how it is currently?

We come back to the problem of aligning IDs. I think the best place to
solve this is in the gump descriptors. Here is how I'd parse them out
in order of preference:
* GroupId:
1) <project groupId="">
2) <module groupId="">
3) <module name="">
* Artifact ID:
1) <jar artifactId="">
2) <jar id="">
3) <project artifactId="">
4) <project name="">
* Type:
1) <jar type="" />
2) <jar /> means "jar"
3) <project type="" />
4) how do you specify non-jar outputs?
* Classifier:
1) <jar classifier="" />
2) <project classifier="" />
3) default is none

If I start adding them, will it break anything?

Now, the next issue comes when Gump3 parses multiple input formats. I
don't want to duplicate information in Maven - can we get gump to pick
a format and produce that as part of the build, regardless of its
input? A POM would simplify things :)

Ok, this would have a preinstalled Maven using some packaged plugins
working offline without a manual repository setup.

Next, to build Maven. We have a bootstrap that runs without any
dependencies except Java that would produce the installation above -
but it downloads the Maven dependencies on the way. We could have it
resolve packaged versions of those by reusing the gump resolver.

Alternatively, something we are doing so it can be packaged on unix is
checking out the sources rather than relying on packaging, then
building them, then building m2 (and those packages would later be
rebuilt again using the new m2). Is that a better alternative to the

- Brett

On 11/16/05, Stefan Bodewig <> wrote:
> On Tue, 15 Nov 2005, Leo Simons <> wrote:
> > Actually, someone's looking at changing the excalibur build to use
> > maven 2. That pretty much means tree detoriation anyway. We're going
> > to start seeing that all over apache as projects migrate to maven 2.
> Pluto's trunk has already jumped to Maven 2.  We will need a maven2
> builder, that's "all".
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message