gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@opensourceconnections.com>
Subject RE: commons-compress - Gump/Maven issues?
Date Mon, 21 Jun 2004 16:32:56 GMT
I don't know what extent you want to push back on the projects that gump
builds, but it seems to me that they are either doing something that pushes
maven beyond it's limits, or the decriptor might be out of date.

I checked out jakarta-commons-sandbox/compress to investigate furthur, but I
don't see this descriptor property you are talking about..  Could you
enlightenme on this?

Eric

> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Monday, June 21, 2004 5:30 PM
> To: Gump code and data
> Subject: Re: commons-compress - Gump/Maven issues?
>
>
> On Monday 21 June 2004 22:47, Stefan Bodewig wrote:
>
> > (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.
>
> If no Maven guys are around... My wild guess would b to try to set
> pom.currentVersion property instead. Then it is a question if Maven
> overwrites it or not...
>
> > (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.
>
> Sorry, this is beyond my knowledge, but hardly surprises me.
>
> > 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.
>
> Generally, Maven will happily download the required Jars from remote
> repositories, which normally can be disabled by running off-line
> mode (-o).
> However, what it builds today will be available in the local
> repository for
> use tomorrow, so I guess you are missing to nuke the local repository (
> normally in $HOME/.maven/repository)
>
>
> Cheers
> Niclas
> --
>    +------//-------------------+
>   / http://www.bali.ac        /
>  / http://niclas.hedhman.org /
> +------//-------------------+
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message