cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [GUMP] Build Failure - cocoon-block-fop
Date Tue, 08 Apr 2003 11:37:11 GMT
on 4/8/03 11:31 AM Gump@icarus.apache.org wrote:

> fop-compile:
>     [javac] Compiling 3 source files to /home/rubys/jakarta/cocoon-2.1/build/cocoon-20030408/blocks/fop/dest
>     [javac] /home/rubys/jakarta/cocoon-2.1/src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java:70:
cannot resolve symbol
>     [javac] symbol  : class Options 
>     [javac] location: package apps
>     [javac] import org.apache.fop.apps.Options;
>     [javac]                            ^

YES! we have a dependency-clean gump run!!!!!!!!!!!!!!!!!!!!

This means that from today on, if you break gump *YOU FIX IT*!!!

This means:

 1) if you update a library, make sure that the gump descriptor reflects
this (look at the very bottom of gump.xml. if the library you are
updating is not there, it means that gump will pick it up from CVS, so
you are all safe, if not, update the dependency)

 2) gump is your friend. it will help you staying on the bleeding edge
without loosing too much blood. learn to treat him well and he'll be
your best friend.

 3) nags are suggestions, not something that is done to annoy you. aim
to clean gump runs as much as you aim to keep the HEAD compilable. The
reason for this is that while a compilable HEAD allows other committers
to keep working, a clean gump run allows other *PROJECT* to keep working
in the future.

Now, we have to fix this FOP issue.

There are two options:

1) run against a particular FOP tag

2) update our code to latest FOP snapshot

which one would you like?

-- 
Stefano.



Mime
View raw message