Hi Andreas. On 28/02/2011 22:51, Andreas Tille wrote: > Hi, > > I would like to refresh my question about the problem I mentioned. > Here again a short summary: At > > http://people.debian.org/~tille/packages/beast-mcmc-help-wanted/ > > you can find a source package of beast-mcmc. All preconditions which > are not available in Debian are at > > http://people.debian.org/~tille/packages/figtree-help-wanted/ > > The problem: Some of the wrapper scripts just find the jam library > and some don't for a reason I can not find. I have too issues with your packages, but they don't match with those you're describing here. Let me try to sum up which problems I'm encountering, so we see if we agree on them. If I just compile and install you're packages and then fire, for example, beast-mcmc, the programs starts correctly and asks me to select a file for loading. Then I give it one of the examples (Flu.xml), and then the program fails because it can't find jebl/evolution/trees/RootedTree. Second try: the manifest for beast.jar is > Manifest-Version: 1.0 > Ant-Version: Apache Ant 1.8.0 > Created-By: 1.6.0_18-b18 (Sun Microsystems Inc.) > Built-By: giovanni > Class-Path: lib/itext-1.4.5.jar lib/beagle.jar lib/mpj.jar lib/org.boehn > .kmlframework_20090320.jar /usr/share/java/junit4.jar /usr/share/java/fi > gtree.jar lib/colt.jar lib/options.jar lib/mtj.jar /usr/share/java/jam.j > ar /usr/share/java/jdom1.jar /usr/share/java/jebl.jar /usr/share/java/co > mmons-math.jar > Main-Class: dr.app.beast.BeastMain This means that starting beast-mcmc with the command java -jar /usr/share/beast-mcmc/lib/beast.jar should automatically search for classes in all the specified classes. Unfortunately the virtual machine fails with the same error as before: it cannot find jebl/evolution/trees/RootedTree (which is in /usr/share/java/jebl.jar, that is clearly included in the classpath). I don't know why. Third try: if I explicitly set classpath with this line java -cp /usr/share/beast-mcmc/lib/beast.jar:/usr/share/java/jam.jar:/usr/share/java/jdom1.jar:/usr/share/java/jebl.jar:/usr/share/java/commons-math.jar dr.app.beast.BeastMain then the program starts, accept the Flu.xml file and starts thinking, writing some funny numbers on the screen (which I assume is a method to say me "Hay man, things are wonderful here and I'm working happily"). The command line: java -cp /usr/share/java/jam.jar:/usr/share/java/jdom1.jar:/usr/share/java/jebl.jar:/usr/share/java/commons-math.jar -jar /usr/share/beast-mcmc/lib/beast.jar (which in my opinion should be equivalent to the previous, but clearly is not) doesn't work. The program still fails finding the same class from jebl. Probably the mechanism the virtual machine uses to search classes when invoked with the "-jar" option isn't totally clear to me (nevertheless, I'm sure that the Class-Path field in the manifest has some meaning, because if I take it out from some JAR that actually works with -jar, it doesn't work anymore). I'm not experiencing any problem with jam.jar. Could you please specify better how your problem arise? > In addition I found out later that the only wrapper script which is not > referencing the beast.jar archive is beauti which is refering to > beauti.jar. However, this is IMHO totally useless and inconsequent > because beauti.jar contains a complete subset of all the classes in > beast.jar and I see no reason why we should carry this copy of code > for no obvios reason (except that if I try to rewrite the wrapper for > beauti I run in the same problem as for treeannotator and treestat > script which are not finding jam). > > A thinkable alternative would be to change the build system in a way > that all wrappers would be use different jars and these in turn should > use one common jar as library. While for my feeling this would be the > technically cleanest solution I doubt that upstream is really happy > about this change and without upstream support for the next versions > such an effort seems to be not very reasonable. Sure it would be better to have just one copy of each class in the package. Having more than one if just a waste of space. I think another acceptable alternative (and probably easier to implement) would be to have all the classes in the same big JAR, using a different main class for each application you want to run. Of course this would mean that you couldn't use the "-jar" option (which is not a big problem if -jar doesn't work anyway). However, other than the waste of space, I don't see any big problem with having duplicate classes, given that they originate from the same source code and are automatically kept in sync. Ciao, Giovanni. -- Giovanni Mascellani <mascellani@poisson.phc.unipi.it> Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascellani@jabber.org / giovanni@elabor.homelinux.org
Attachment:
signature.asc
Description: OpenPGP digital signature