On Tue, Jan 10, 2012 at 12:01:57PM +0100, Olivier Sallou wrote: > >> Usually, this kind of problem is due to the CLASSPATH not containing > >> jam.jar > > $ grep jam debian/rules > > export CLASSPATH := > > $(DEBJAR)/itext.jar:lib/beagle.jar:lib/mpj.jar:lib/org.boehn.kmlframework_20090320.jar:$(DEBJAR)/junit4.jar:$(DEBJAR)/figtree.jar:lib/colt.jar:lib/options.jar:lib/mtj.jar:$(DEBJAR)/jam.jar:$(DEBJAR)/jdom1.jar:$(DEBJAR)/jebl.jar:$(DEBJAR)/commons-math.jar > > > > As far as I understood you do not need to explicitely set CLASSPATH at > > runtime (and it would not explain why the other executables are > > perfectly finding the needed jars. > > For classpath, at runtime, all depends on how jar is generated. If it > contains a MANIFEST file with the classpath defined, it will be able to > find the JARS (supposing that libraries path are the same). If it dies > not contains the classpath in the MANIFEST file, classpath must be set > explicitly to each jar file in the command line (usually via a wrapper > shell)
Apropos MANIFEST: I formerly fiddled around with packaging using jh_manifest and there is also some alternative packaging method at http://people.debian.org/~tille/packages/beast-mcmc-help-wanted/manifest/ featuring a debian/beast-mcmc.manifest file. Believe it or not it shows the very same behaviour. The most strange fact for me is that the two executables loganalyser and logcombiner are very similar but only one of them runs and the other fails. Do you think I should simply add a CLASSPATH variable to those scripts that are failing without understanding why the others are working? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120110131155.ga1...@an3as.eu