Bret/Adam:
Just a note on this dependency mapping question .. within the Magic
build system we doing something similar. Dependencies declared in a
magic project definition typically match up with the name of an artifact
(id in maven). In cases where Gump declares a scoped name (e.g. junit
relative to the ant-junit project, we include additional meta info
within the magic project definition (loosely equivalent to maven's
project.xml).
Here is an example of the definition of an external resource (close to a
maven <dependency> declaration). Within magic the groupId is 'ant' and
the artifactId is 'ant-junit'. We have additional metadata to handle
the mapping to a gump alias/id combination. Using the alias/id we can
automatically resolve the gump resource and allocate this to the project
group/name key.
<resource>
<info>
<group>ant</group>
<name>ant-junit</name>
<version>1.6.2</version>
<type>jar</type>
</info>
<gump>
<classpath/>
<alias>ant</alias>
<id>junit</id>
</gump>
</resource>
This works quite well and we don't have any naming conflicts.
Cheers, Steve.
p.s. Just another thought - the build.properties file generated by Gump
seems to be including all inherited project references irrespective of
the definition in gump. For example, I recently removed all of the
inherit attributes from the gump descriptor for the threads project
(bringing it in line with the maven generated gump task output, but the
properties file still contains a much larger set of dependency mappings.
Would it be possible to simply restrict gump to generating only those
properties that are explicitly declared (i.e. no inherited properties)?
Cheers, Stephen.
> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 24 September 2004 05:24
> To: Gump code and data
> Subject: Re: excalibur-thread-impl failure in Gump
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
