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 unique. At the moment, groups are things like commons-collections, ant, and maven (see the root directory of http://www.ibiblio.org/maven/ 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 respectively. > > 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 project.xml. 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 same. > 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. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
