gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject RE: Gump integration with Maven
Date Thu, 13 May 2004 23:33:44 GMT
> > So, to sum up this point: I think gump should have just one 
> id for a 
> > project,
> What about projects that produce multiple jars?

Sorry... I didn't realise that gump had a notion of a project that produces
multiple artifacts. In maven, project to artifact Id is 1:1, however a
project can produce multiple different 'types' of the same artifact (eg,
documentation, jar, or maybe different types of dist: src, bin, etc)

So if gump has a project id and a jar id under that which is usually the
same, this sounds something like groupId:artifactId. But to keep it simple -
one gump id per jar produced sounds ok.

> > If this needes to be done alongside ant projects, I'll 
> leave it up to 
> > the gump folk to decide how this is best treated.
> I'm not sure whether I parse this correctly.  There will 
> always be projects that want to be built by Maven but depend 
> on things that have not been built by Maven.  So we'll have 
> to make up some ids - or use those that have been made up by others.

Ok, I see your point. Maven projects will have been built against these
assuming the structure in ibiblio, so it seems that gump will have to match
up the artifactId in there regardless.

> > The downside to this, is I imagine a bunch of Maven plugins 
> will freak 
> > out at more recent versions of Jelly or other things, and 
> this could 
> > hold up this part for a while to fix it.
> <tongue-in-cheek>Aren't you going to release Maven and the 
> plugins rather soon?  Wouldn't you want your plugins to work 
> with latest Jelly?</tongue-in-cheek>

We'd love for it all to work with the latest Jelly and Ant, but the current
structure has prohibited upgrading without a high risk. Post-1.0 this will
be revisited.

> Seriously, since we are trying to get things working in the 
> first place, we may be better of with using a more 
> conservative approach and switch to the mode you propose here 
> later - once we have a working setup.




  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message