The commons-logging ant build has been customised from one generated by
Maven. The Maven build does not produce the api JAR, although it could
easily be modified to do so in one of two ways:
- a custom postGoal on jar:jar in maven.xml to produce the second JAR with
the same ant code as is in build.xml
- a new goal that gump calls differently (eg
commons-logging:generate-api-jar prereqs="jar:jar")
- a sub project with artifact id commons-logging-api that takes the original
source directory with the relevant exclusions

I don't see a problem with either as long as gump can handle it. The third
is probably the preferred Maven solution and would fit with what we've been
discussing and is a much shorter solution (a cut down project.xml that
extends the original and overrides the source directory).

Either way, the groupId remains commons-logging, with the artifactIds being
commons-logging and commons-logging-api.

Cheers,
Brett

> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, 15 May 2004 1:00 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Gump integration with Maven
> 
> 
> On Fri, 14 May 2004, Brett Porter <[EMAIL PROTECTED]> wrote:
> 
> > Sorry... I didn't realise that gump had a notion of a project that 
> > produces multiple artifacts.
> 
> Hmm, commons-logging is built by Maven.  Its Ant build file 
> produces two jars, commons-logging.jar and 
> commons-logging-api.jar - how does Maven deal with this?  Are 
> these two separate projects?  Or a group of two artifacts?  
> This is the case we need to get mapped when running Gump.
> 
> Stefan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

Reply via email to