gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject RE: Maven and gump
Date Wed, 26 Nov 2003 21:23:52 GMT
> Historically it has been phase 1 and even succeeded at one 
> point. Currently Gump's inability to build dom4j or jaxen is 
> probably the biggest problem for getting Maven built.

I must have missed something... So gump can't use any JARs it doesn't build

> No problem with working from an installed Maven first, but 
> we'll have to ensure it gets maintained (i.e. updated with 
> each new milestone, RC).

Happy to help looking after that. One issue will be the plugins... We have
slated some work for 1.1 to clear up how different versions will interact,
but at the moment certain projects may need a variety of plugin versions.
They can specify dependencies to make sure they get used, but we might need
to make sure they get removed again so they don't interfere with other

> > Another (better?) alternative is to have Gump switch the 
> descriptor at 
> > build time via XSLT or something, so that all the dependencies it 
> > knows about use the version SNAPSHOT instead of the one specified.
> How would that work?  I'm pretty ignorant about Maven.

SNAPSHOT is sort of the identifier for "latest build". So if gump were
building snapshots, Maven could use them. This is a very mavenish solution
though, because there'd need to be a way to create and deploy snapshots for
non-Maven projects (not difficult - just an appropriate move command).

> Can Gump say the SNAPSHOT is the jar I've just built there or 
> would that require SNAPSHOTS to be available in some 
> repository?  If the later is the case, it looks as if jar 
> overrides were the better option to me.

Yeah, at least for the being, I think you might be right. Jar overrides seem
to match the current model perfectly and are easy to set up.


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