From: E.L. W. <eg...@sc...> - 2004-08-12 12:03:33
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 August 2004 13:26, Daniel Leidert wrote: > Egon Willighagen wrote: > > On Thursday 12 August 2004 11:30, Daniel Leidert wrote: > The account-name is "dleidert". Ok, I'll add you. > > > > > > I also saw the libcdk-java-plugins package! Excellent! But how = do > > > > > > you make those? There are no source tar.gz packages for them > > > > > > (maybe there ought to be...) > > > > > > > > > > I built the package from the cvs-soure. > > > > > > > > Ok, good. Gonna download the sources then to see how that works, i.= e. > > > > making a deb package from CVS... > > > > > > That's no miracle. Checkout the cvs-sources, copy them to a renamed > > > directory, delete the CVS-directories with the find-command (lintian > > > will complain about CVS-dirs) and then it's the same way as always > > > (dh_make ...). > > > > No special debian scripts for that? > > No. Even the Makefile is overkill (in this case). All needed steps can > be done by the rules-file. Sounds good. I think the packages are of much higher quality than mine :) > > > > I appreciate very much what you're doing... > > > > > > Then I hope you like the new packages (libcdk-java-dirbrowser0.8, > > > libcdk-java-rssviewer0.12, ..). > > > > Is the plugin version number in the package name? (Yes, it seems so...) > > Is there a reason to include the version number in the name? > > Yes, there are several reasons. The first one is, that the plugins are > built against the libcdk-java package. So I wanted to include the > version of libcdk-java for a logical connection between the version > numbers. But then it's really hard to declare a version like > 20040626-0.8+1 for revision and plugin-version (lintian complains about > this). The next reason is, that maybe in future a new plugin-version > will broke with an updated jchempaint/jmol package. Then it is IMHO good > to have a 2 plugin-versions, which can be installed beside each other. > With this type of labelling the packages, it should be possible. > > The actual version-labelling follows this aim: > libcdk-java-dirbrowser0.8 (20040626-1+1) > > 0.8: version of plugin > 20040626-1: version of libcdk-java > +1: revision of package Ack. Sounds like good thinking... > > > > > > another advantage of seperate packages for the plugins, would be > > > > > > that e.g. Jmol could Suggest: plugins that really work... > > > > > > > > > > It seems, that no plugin works correctly with jmol-9 except > > > > > cotviewer. > > > > > > > > I haven't tested them with it for some time... and work on 9 has > > > > actually stopped since we are focusing on the 10 release... > > > > > > There was a problem in the jmol-9-source. The old-jar-target in > > > build.xml pointed originally to mutli.jar, not to multi.jar. I didn't > > > saw this. So the package was mostly unusable till -3. This is fixed > > > now. The dirbrowser-plugin should work with a version >=3D -3 (tested= ). > > > Dito for the macieplugin. > > > > Excellent! > > > > > rssviewer is definitely not working with jmol-9. > > > > Ok, I'll see if I can do something about that... > > Only if this is really necessary. Jmol-9 is a bit old. Maybe it would be > the best to wait for the release of version 10. Ok. > > > > > > 3. the README mentions users to have to make a symbolic link or > > > > > > copy the files... my actual intention was to have a global plug= in > > > > > > dir for Jmol and JChemPaint, e.g. /usr/share/libcdk-java/plugin > > > > > > :) I'll work on some patches upstream :) > > > > > > > > > > I added an option "-p" to /usr/share/jchempaint (documented in the > > > > > man-page). If this option is called, > > > > > -Dplugin.dir=3D/usr/share/libcdk-java/plugin is set as command-li= ne > > > > > parameter. > > > > > > > > Is there a special reason why you overwrite the options of the jar > > > > file itself? > > > > > > I don't know, what you mean(?). > > > > How did you add the -p option? > > In the shell-script (usr/bin/jchempaint). The script tests, if there is > an option "-p". If so, it adds -Dplugin.dir=3D/usr/share..... to the > command. I don't like the idea, that the -Dplugin.dir-option is set > globally. On multi-user-systems maybe not every user wants to use all > installed plugins. Ack. > > I assumed in the shell wrapper... Or did you > > add it the the Java code, and have the script now pass on parameters to > > the application? > > The script is only testing for the -p option. All other options are > given directly to command-line, like described in the manpage. > > > > > > So every user can still choose, which plugin(s), he want to > > > > > use (by making a symlink or copy them to his home-dir or calling > > > > > all with the -p option). A new version (-4) is up at mentors. May= be > > > > > it is an idea for one of the future jchempaint-releases, to add an > > > > > option (-p, --plugin or -ip, --includeplugin) that an compiled-in > > > > > path for -Dplugin.dir is called. > > > > > > > > The problem is that there is not really a default directory... For > > > > Linux, it's reasonable standard, but it needs to work with other > > > > platforms too, hence the current implementation... > > > > > > My idea was, to make an optional option, to point to a compiled-in-pa= th > > > for plugins (analogue to the compiled in path to > > > ~/.jchempaint/plugins/, but it should only work, if this special > > > command-option is used). E.g. if I compile it for Debian, I set this > > > special variable to > > > /usr/share/libcdk-java/plugin, so if someone calls the -p-option, he > > > will get all installed plugins from the compiled-in-path. If someone > > > compiles it for RH, maybe he sets it to /usr/share/cdk-plugins (or > > > whatever). > > > > I see your point, but that would mean the projects could no longer > > distribute binaries, i.e. they would need to make a separate binary for > > each platform, and the nice thing if Java is that that is not required.= =2E. > > I don't think so. This variable could be left blank (e.g. for binaries). > It should only be used/set (from the maintainer of a package), when > compiling a package from source. It should be only the possibility to > define a global plugin-dir (only to define the unset -Dplugin.dir option > when compiling), which is used, if the -p option is called. If there is > no path compiled in, the -p option could echo something like "unset" or > "not defined". That sounds like a good proposal... <snip> > This is also a possibility, but maybe overkill(?). Yes, I like yours more too. Egon =2D --=20 eg...@sc... PhD on Molecular Representation in Chemometrics Nijmegen University http://www.cac.sci.kun.nl/people/egonw/ GPG: 1024D/D6336BA6 "Again a chemist did something useful with a computer" =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFBG1yKd9R8I9Yza6YRAnBrAKCtRHxLHtVqCHEk2OVFYQdXldfTPgCbB+nM PfubSbsIky2nfP6zSovsxVc=3D =3DZw9f =2D----END PGP SIGNATURE----- |