commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [GUMP@brutus]: Project commons-jelly-tags-swing (in module commons-jelly) failed
Date Wed, 19 Jan 2005 10:05:24 GMT
If you are referring to this:

You are working offline so the build will continue, but commons-jelly-SNAPSHOT.jar may be
out of date!

That's not the case. Gump builds commons-jelly first, and Maven is using 
that via a JAR override, so whether it is SNAPSHOT or not, its still the 

I'll address each coment, but I don't think there is a problem. The 
swing one broke because java.awt.headless was not passed:

Paul Libbrecht wrote:

> This break is related very exactly to the fact that the snapshot is  
> dead-old at least the one that is downloaded fresh when you run 
> "maven  jar" within a taglib directory without having, previously, run 
> "maven  jar:install-snapshot". This is the case of gump and probably 
> many  people downloading...
> Let's discuss the possible ways for a long-lasting solution for this  
> because I am sure we're not the only ones trying to have a federation  
> or projects:
> - having SNAPSHOT builds at ibiblio uploaded regularly (e.g from 
> GUMP).  I would favour this, especially since Maven had such a 
> sentence. Is it  possible Brett ?

Probably not to ibiblio. But certainly, Maven can do this if a proper 
home is found.

I don't suggest using gump for this, as you are building against 
something the project descriptor is not.

> - modify the maven.repo.remote properties so that our Jakarta (or  
> Apache?) repository is used instead. That's not bad style but, due to 
> a  bug in maven, it is not possible to use this aside of personal or 
> group  maven.repo.remote (e.g. in ~/  which, I feel, 
> makes  sense and should be used, e.g. for commercially licensed stuffs 
> or  for...)

bug can be fixed in 1.1.

> - use Jar overrides for the taglibs projects so that the referenced  
> commons-jelly-xx.jar is in ../../target/. We need to keep things in  
> sync but that looks doable.

I don't think this is a good idea in general, and it is not necessary 
for Gump.

> - let gump only build a complete jelly build, not each separate  
> taglibs, thus ensuring this jar is produced

already does this.


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

View raw message