gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject commons-compress - Gump/Maven issues?
Date Mon, 21 Jun 2004 14:47:01 GMT
Hi all,

two notes colored by my complete lack of Maven knowledge:

(1) The descriptor of commons-compress sets a property named
component.version and hopes to get this into the jar name, which
obviously doesn't work that way.  Maven still uses
/project/currentVersion from the POM.

I've adapted the descriptor to match the name we actually see just to
get a successful build in Gump, but I'd prefer a way that allows us to
get dated jar names via Maven.  Probably we are just using the wrong
property name or something like that.

(2) The <work> entry inside the descriptor pointed to nowhere and
there is no <work> entry for the generated test classes, still the
test goal manages to load the freshly compiled test classes.

This means that we are not getting the effect of
build.sysclasspath=only in Maven builds.  The jar overrides will catch
the artifacts Gump knows about but Maven will happily let the goals
(plugins, tasks, I don't know the correct terms) add more stuff to the
classpath itself.

For things like <work> directories for compiled classes this probably
is good, but it may also lead to situations where Gump doesn't manage
to substitute a jar from CVS with a freshly compiled one.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message