gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: excalibur-thread-impl failure in Gump
Date Fri, 24 Sep 2004 03:23:47 GMT
Ok, this time I got the reply-to right :)

> Unfortunately it has "junit", the reason being was that Gump 'jar ids' were
> within the scope of the project, so the 'ant' was implied. Since Gump only
> has 'jar id' that is the only thing that Gump can pass to Maven. Hence we
> need to make Gump 'jar ids' globally unique, and (for want of a better)
> match Maven 'artifact ids'.

Ok, I should explain Maven id's to clear this up a bit. They are
composed of a group and an artifact ID. The group must be unique (this
is easier to control than the whole id being unique), and the
artifactId must be unique within the group (also easy for those
maintaining the group to control). This guarantees the whole ID is

At the moment, groups are things like commons-collections, ant, and
maven (see the root directory of for a
list), but eventually we intend to move to a package structure, so the
group would be org.apache.ant and such.

The notation for an id is groupId:artifactId.

Usually, artifactId is the same as the filename (files are built as
artifactId-version.jar by default). This makes it much easier to
remember and look up.

For the above example, the ids should be junit:junit and ant:ant-junit

> > JAR overrides do have a limitation in that they currently don't really
> > support the Maven id structure of group:artifact, which is planned to
> > be fixed for 1.1.

So what I was saying here is that we never used to have a groupId -
and the overrides you are using are a hangover of that. The property
must match either the <artifactId> or <id> part of a dependency in

But if we have a project with ant:junit and junit:junit as
dependencies - there'll be a problem as in both cases the old id is
just junit.

> If you have time to explain in more detail I'd appreciate that, I'm not
> quite following.

Hope this helped.

> I agree. I was saying "correct" because I thought it used "junit", so I feel
> it ought ask for it (not have Maven transparently add it).

In this way, Maven attempts to separate the build from the actual
produced JAR (it isn't always successful, but we're working on that :)

excaliber doesn't depend on junit in any way to use it AFAIK, so its
not a dependency. It is a dependency of the excalbier unit tests
though. Maven will specify that for you to avoid having to do it
yourself only if you use the test plugin. In the same way, checkstyle
is not a dependency of excaliber - but it is used if you run the maven
checkstyle plugin report.
Tests admittedly are a bit more fuzzy because you code and compile
portions of your source against junit, but it should be treated the

> Or we build Maven from scratch using Gump'ed artifacts?

I think this can happen now if you are game to try. Start by building
from MAVEN-1_0-BRANCH and then later move to HEAD. If you want to
build a Maven distribution using Maven 1.0, that's doable now. If you
want to use ant 1.5, I'd need to modify the bootstrap to accept JAR
overrides. Which do you prefer? Maybe start with Maven and work back
to Ant?

Thanks for your feedback Adam. Let me know what I can do for you.


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

View raw message