OK Here's what I'v done.
download xalan-j_2_4_D1 xerces-2_0_2 and fop-0.20.4rc
added JAVA_HOME and CLASSPATH to my .bashr file
JAVA=/usr/java/j2sdk1.4.0_01
JAVA_HOME=/usr/java/j2sdk1.4.0_01
CLASSPATH=$JAVA/lib
PATH=.:$DBROOT/bin:$DBROOT/pgm:$PATH:$JAVA/bin:/opt/pstill_dist:$JAVA/bin:~/myscripts:/usr/java/j2sdk1.4.0_01
cd into /usr/java/j2sdk1.4.0_01
run fop.sh and receive
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/fop/apps/Fop
echo $CLASSPATH
/usr/java/j2sdk1.4.0_01/lib
echo $JAVA_HOME
/usr/java/j2sdk1.4.0_01
This is almost as much fun as trying to get debian to run on an IBM
760XL thinkpad. Which by the way I haven't succeeded in doing
either.Maybe we can work on that next :)
Mike M.
On Mon, 2002-08-05 at 12:24, Derek Glidden wrote:
> On Mon, 2002-08-05 at 09:03, Mike Manchester wrote:
> > I know there must be a secret Java Society because there is a lot of
> > hidden or missing information about setting up and using Java. I mean
> > most distro don't even install it as default and if you elect to install
> > it after wards it's not easy to find out how to install it. Install the
> > package files don't do much.
> [big snip]
>
> Hi Mike,
> Java's not really hard, there are just things you must understand about
> Java programming before it gets really easy. Kind of like when you try
> to compile a C app, and you get an error like "can't find
> linux/versions.h" (or whatever) and it bombs out. It's not entirely
> clear what the error means, but it's easy enough to fix.
>
> JAVA_HOME just needs to point to the root directory where you installed
> the JDK. So if, for example, the JDK got installed in
> /opt/j2sdk1.4.0_01, then you would set JAVA_HOME to "/opt/j2sdk1.4.0_01"
> like:
>
> bash$ export JAVA_HOME=/opt/j2sdk1.4.0_01
>
> Then you need to make sure the 'java' and 'javac' executables are in
> your path. They should be under "JAVA_HOME/bin" so you can try
> something like this:
>
> bash$ export PATH="$PATH:$JAVA_HOME/bin"
>
> and then type:
>
> bash$ which java
>
> and hope it comes back with something found.
>
> Really, that's all it takes to get the JDK working. But then if you
> need to compile something, it can get harder, particularly stuff from
> Apache group, since they tend to have lots of dependencies.
>
> JAR files are just like library files for Java. In C programming, you
> have .a or .so files, for anything not in libc, which you need to tell
> the linker to also use, by adding something like "-lm" or "-lXlib" onto
> the compile command-line. In a similar way, you need to put those
> dependency .jar files somewhere the JDK can find them, and also tell it
> to include those .jar files when it compiles. You do that with the
> CLASSPATH. So if you put everything in /opt/classpath, then you can
> set:
>
> bash$ export CLASSPATH=$JAVA_HOME/jre/lib/rt.jar:.:/opt/classpath
>
> and the JDK will first look at its default runtime lib (I think newer
> versions of the JDK automatically do this, even if you set the CLASSPATH
> var explicitly - older versions would _only_ look at the CLASSPATH var),
> then in the current directory, then in /opt/classpath for extra .jar
> files.
>
> Download those dependency JAR files, put them in /opt/classpath, then
> _hope_ that the build script with your application works correctly. If
> the build script isn't using make or ant or something that tries to
> handle all the directories and paths, then you're going to have to edit
> it manually and there's not much you can do about that.
>
> JAR files are a little odd in that they're really just ZIP files of a
> particular directory structure. If you use the 'jar' tool (or the
> 'unzip' utility) you can see what files are in a jar file. It will look
> just like a zip or tar of a bunch of class files. Since you can only
> have one Java class with a particular name, projects tend to group them
> in heirarchies based on their domain name. So stuff from the Apahche
> group will put their class files in directories like
> org/apache/projectname/somefunction/classname - so you can always look
> in your JAR files to look for those "missing class" classes that might
> generate errors. You may just be missing another JAR file.
>
> The good thing about Java though, particularly non-GUI Java apps, is
> that they really are mostly compile-once-run-anywhere, so you should be
> able to just download a "binary" version of the application you're
> trying to run and get it working pretty quickly, following the advice on
> getting the JAVA_HOME and CLASSPATH vars set properly, and getting all
> the dependency .jar files downloaded and put in the right places.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> #!/usr/bin/perl -w
> $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
> {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
> $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
> [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
> "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
> unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
> >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
> 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
> print+x"C*",@a}';s/x/pack+/g;eval
>
> usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
> | extract_mpeg2 | mpeg2dec -
>
> http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
> http://www.eff.org/ http://www.anti-dmca.org/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:53:54 EDT