From: Egon W. <eg...@sc...> - 2004-08-07 11:57:52
|
On Saturday 07 August 2004 10:40, Daniel Leidert wrote: > I write to you, because you maintained the Debian-packages for jmol and > jchempaint (jcpcdk) in the past. > > I now compiled Debian-packages (for i386-architecture) for the actual > versions of these two programs and they work excellent for me. If you > agree, I will upload them to mentors.debian.net. Good. I'm short of time, so please go ahead. Thanx! BTW, which versions did you package? > But there are a few > questions, before I can do this. These two packages are my first > Java-based packages, so there are things unclear. But you have Debian package building experience? I'm a bit short on knowledge in that part... > I compiled them > against some packages like libgnujaxp-java, libcommons-cli-java, > libitext.java,... . But I don't know, if a have to write these packages > to the package-depends. All JChemPaint and Jmol packages have all required libraries distributed along. (Note that I have not figurered out if GPL/Apache combo violates licenses etc... both projects have not bothered with that yet...) But, because Debian already has some of those libraries in other deb packages, it's better to use those... I think for both programs, I made a Makefile with a target called deb, or so... this should delete jars from the tar.gz provided by other debs, and adjust build.xml to match the new location for that jar. Jmol and JChemPaint at least use the jars in the first two debs you mention above... and they are both a build and a runtime dependency... (but the first implies the second, correct?) > If my understanding of the build-process is > correct, I don't need any of the *.jar-files or these packages for > installing and using jmol.jar or jchempaint.jar. Is that right? You do. The Debian JCP/Jmol package should not include libraries provided by other Debian packages... > I am > also a little bit confused, about the package-depends from jcpcdk (I now > call the package jchempaint) on cdk. Why are they neccesary? For me, it > looks like, that I only need them for building jchempaint(?). CDK is the core library on which JChemPaint is build. You need the CDK library on runtime too... > One question at last: How do you build the libcdk-java and cdk-package? > The reaseon, why I ask is, that I maybe will try to update this package > too. It should be possible to use one source tar.gz to create more than one deb package... my original idea was to make one deb with the library part only, and one part with executables... the first would never depend on Swing stuff while the executables could depend on that... But this was did not really work out (lack of deb package building experience...) It's better to make just one libcdk-java package again... > There are configure- and Makefile-scripts in your last uploaded > source. Did you write these scripts? I Can' find them in cvs. It's not in cdk/packages/debian/cdk ? > Is it > really necessary to divide the source into 2 packages (in your opinion)? I no longer think this is necessary... > I hope, you can help me, to answer these questions. If you want, you can > have a look at the packages under > > http://www.wgdd.de/cgi-bin/sitexplorer.cgi?/debarchiv/dists/unstable/contri >b/binary-i386/ I will try to find time later... Egon |
From: Daniel L. <dan...@gm...> - 2004-08-08 20:32:27
|
Egon Willighagen wrote: > On Saturday 07 August 2004 15:27, Daniel Leidert wrote: > > Am Sa, den 07.08.2004 schrieb Egon Willighagen um 13:56: > > > On Saturday 07 August 2004 10:40, Daniel Leidert wrote: The last question answered first > > > PS. can we continue this discussion on the cdk-devel@ list? Yes, of course. > > This is my question. In build.xml you expand the needed jars to > > appjar.dir and then you build from this source the jmol.jar and > > jchempaint.jar. In your jmol-Makefile, you don't install the jars > > provided by the source to /usr/share/$package/lib. So I thougt, that all > > needed classes/libs are built in the resulting jar and there is no need > > for runtime-dependencies(?) on e.g. libgnujaxp-java or other related > > packages. > > Good point. You need to use the old-jar target in the build.xml... this will > make a classpath depending jar... i.e. will not put all jars in one big > jchempaint.jar... Ah, ok. This clears the question. I used the jar-target (see the Makefile). > > > > If my understanding of the build-process is > > > > correct, I don't need any of the *.jar-files or these packages for > > > > installing and using jmol.jar or jchempaint.jar. Is that right? > > > > > > You do. > > > > I need them for the build-process. But for the runtime? > > Yes. For the old-jar target. Now I see it, ok. > > > The Debian JCP/Jmol package should not include libraries provided by > > > other Debian packages... > > > > > > > I am > > > > also a little bit confused, about the package-depends from jcpcdk (I > > > > now call the package jchempaint) on cdk. Why are they neccesary? For > > > > me, it looks like, that I only need them for building jchempaint(?). > > > > > > CDK is the core library on which JChemPaint is build. You need the CDK > > > library on runtime too... > > > > Are you sure? The same way. > > Yes, because the debian build process should use the old-jar target, instead > of the jar target... I think, this is a question of belief. There are some advantages and some disadvantages. I will ask in the debian-user(-german)-mailing-list, what other people think about this problem. > > If there are no problems with the jmol- and > > jchempaint-package, i will try to compile it. > > Ok, thanx. It will need a week or two, but it should be no problem. BTW: I saw, there is a new version of jchempaint up. Regards, Daniel -- |
From: E.L. W. <eg...@sc...> - 2004-08-09 05:17:28
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 08 August 2004 22:33, Daniel Leidert wrote: > > > If there are no problems with the jmol- and > > > jchempaint-package, i will try to compile it. > > > > Ok, thanx. > > It will need a week or two, but it should be no problem. That would be great. BTW, are you using my debian/ dir as a starter... or a= re=20 you doing this from scratch (both would be fine...)? > BTW: I saw, there is a new version of jchempaint up. Yes, I released JChemPaint 2.0.4 yesterday... 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) iD8DBQFBFwjdd9R8I9Yza6YRAppQAJwMA/oDNxIg0MO68JystKqV4dmr7ACgldUX JWkU8Ve2yC043EMD2gHcj60=3D =3DNvdR =2D----END PGP SIGNATURE----- |
From: Daniel L. <dan...@gm...> - 2004-08-09 06:49:22
|
E.L. Willighagen wrote > On Sunday 08 August 2004 22:33, Daniel Leidert wrote: > > > > If there are no problems with the jmol- and > > > > jchempaint-package, i will try to compile it. > > > > > > Ok, thanx. > > > > It will need a week or two, but it should be no problem. >=20 > That would be great. The package (called libcdk-java) is online now on mentors (at the moment built without Java3D and joelib.jar). If cdk is installed, it has to be deinstalled, to upgrade libcdk-java. But there is a compiler-error-message. It seems, that something from swing is needed or not up-to-date. Maybe, you see the problem. The message is: reallyRunDoclet: ... [javadoc] Constructing Javadoc information... [javadoc] libcdk-java-20040626/src/org/openscience/cdk/applications/swing= /dragndrop/CDKDataFlavor.java:26: cannot resolve symbol [javadoc] symbol : class DataTransfer [javadoc] location: package datatransfer [javadoc] import java.awt.datatransfer.DataTransfer; [javadoc] ^ [javadoc] libcdk-java-20040626/src/org/openscience/cdk/applications/swing= /dragndrop/CDKDataFlavor.java:31: cannot resolve symbol [javadoc] symbol : class DataTransfer [javadoc] location: class org.openscience.cdk.applications.swing.CDKDataF= lavor [javadoc] public abstract class CDKDataFlavor extends DataTransfer { ... > BTW, are you using my debian/ dir as a starter... or are=20 > you doing this from scratch (both would be fine...)? A mixture of both :-) Your debian-dir gave me useful infos and suggestions, and these are included in my debian-dir. > > BTW: I saw, there is a new version of jchempaint up. >=20 > Yes, I released JChemPaint 2.0.4 yesterday... It's also online. This version was built with runtime-dependencies and includes the jcpapplet.jar. It seems to work correct. Regards, Daniel --=20 |
From: E.L. W. <eg...@us...> - 2004-08-09 06:55:36
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 August 2004 08:50, Daniel Leidert wrote: > The package (called libcdk-java) is online now on mentors (at the moment > built without Java3D and joelib.jar).=20 Excellent! > If cdk is installed, it has to be=20 > deinstalled, to upgrade libcdk-java.=20 Maybe, we you could put in a Conflict:? > But there is a=20 > compiler-error-message. It seems, that something from swing is needed or > not up-to-date. Maybe, you see the problem. The message is: > > reallyRunDoclet: > ... > [javadoc] Constructing Javadoc information... > [javadoc] > libcdk-java-20040626/src/org/openscience/cdk/applications/swing/dragndrop= /C >DKDataFlavor.java:26: cannot resolve symbol [javadoc] symbol : class > DataTransfer > [javadoc] location: package datatransfer > [javadoc] import java.awt.datatransfer.DataTransfer; > [javadoc] ^ > [javadoc] > libcdk-java-20040626/src/org/openscience/cdk/applications/swing/dragndrop= /C >DKDataFlavor.java:31: cannot resolve symbol [javadoc] symbol : class > DataTransfer > [javadoc] location: class > org.openscience.cdk.applications.swing.CDKDataFlavor [javadoc] public > abstract class CDKDataFlavor extends DataTransfer { ... Ok, you can delete those files... or exclude them from compilation... there= =20 broken... > > BTW, are you using my debian/ dir as a starter... or are > > you doing this from scratch (both would be fine...)? > > A mixture of both :-) > > Your debian-dir gave me useful infos and suggestions, and these are > included in my debian-dir. > > > > BTW: I saw, there is a new version of jchempaint up. > > > > Yes, I released JChemPaint 2.0.4 yesterday... > > It's also online. This version was built with runtime-dependencies and > includes the jcpapplet.jar. It seems to work correct. I'll try them now... 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) iD8DBQFBFx/gd9R8I9Yza6YRAshcAJ4pOoPs+s1DraZUfTDALn7VgfLgZwCguHtJ 7V7Ilmjpn3lAPBWtLBiZHsY=3D =3DkaFw =2D----END PGP SIGNATURE----- |
From: E.L. W. <eg...@sc...> - 2004-08-09 07:20:11
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 August 2004 08:55, E.L. Willighagen wrote: > > It's also online. This version was built with runtime-dependencies and > > includes the jcpapplet.jar. It seems to work correct. > > I'll try them now... Ok, the Packages.gz does not seem updated yet, so I had to manually get the= =20 packages... I've found some issues... but before I post them, I would like = to=20 ask you (Daniel), wether you plan to support these packages or not? If so, we should get you an SF account, so that you can get package bugs assigned,= =20 and maybe put the packaging stuff in CVS... What are your thoughts on that? Here are the two problems I found with the Debian package of JChemPaint... 1. The application starts with no problem, but the DirBrowser plugin is not= =20 available from the plugin menu... it should be in the tar.gz plugin/ 2. When saving CML I get this error: java.lang.VerifyError: (class: gnu/xml/pipeline/DomConsumer$Handler, method= :=20 startDocument signature: ()V) Illegal use of nonvirtual function call at gnu.xml.pipeline.DomConsumer.<init>(DomConsumer.java:115) at gnu.xml.dom.Consumer.<init>(Consumer.java) at gnu.xml.dom.JAXPFactory$JAXPBuilder.<init>(JAXPFactory.java:131) at gnu.xml.dom.JAXPFactory.newDocumentBuilder(JAXPFactory.java:96) at=20 uk.co.demon.ursus.dom.pmr.PMRDocumentImpl.<init>(PMRDocumentImpl.java:62) at=20 org.xmlcml.cmlimpl.AbstractCMLDocumentImpl.<init>(AbstractCMLDocumentImpl.j= ava:56) This one is a problem with a conflict between the cmlCore.jar in CDK, and t= he=20 GNUJAXP (I think) in Debian... 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) iD8DBQFBFyWkd9R8I9Yza6YRAn0CAJ9VoVme+Gdae/FD5UpFRfe/GXXyTQCgt0Md GzFG8DtSgA39OOKB7w+3fG0=3D =3DdCKv =2D----END PGP SIGNATURE----- |
From: Daniel L. <dan...@gm...> - 2004-08-09 09:16:31
|
Am Mo, den 09.08.2004 schrieb E.L. Willighagen um 9:20: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 09 August 2004 08:55, E.L. Willighagen wrote: > > > It's also online. This version was built with runtime-dependencies and > > > includes the jcpapplet.jar. It seems to work correct. > > > > I'll try them now... > > Ok, the Packages.gz does not seem updated yet, so I had to manually get the > packages... I've found some issues... but before I post them, I would like to > ask you (Daniel), wether you plan to support these packages or not? I will support them. If you want to contact me, please use the email-address, given by the packages. > If so, > we should get you an SF account, so that you can get package bugs assigned, > and maybe put the packaging stuff in CVS... What are your thoughts on that? Ok. > Here are the two problems I found with the Debian package of JChemPaint... > > 1. The application starts with no problem, but the DirBrowser plugin is not > available from the plugin menu... it should be in the tar.gz plugin/ Yes, I found the problem. The dir-variable in <target id="old-jar" ..> was not right. This is fixed, a new version is uploaded to mentors. > 2. When saving CML I get this error: > java.lang.VerifyError: (class: gnu/xml/pipeline/DomConsumer$Handler, method: > startDocument signature: ()V) Illegal use of nonvirtual function call > at gnu.xml.pipeline.DomConsumer.<init>(DomConsumer.java:115) > at gnu.xml.dom.Consumer.<init>(Consumer.java) > at gnu.xml.dom.JAXPFactory$JAXPBuilder.<init>(JAXPFactory.java:131) > at gnu.xml.dom.JAXPFactory.newDocumentBuilder(JAXPFactory.java:96) > at > uk.co.demon.ursus.dom.pmr.PMRDocumentImpl.<init>(PMRDocumentImpl.java:62) > at > org.xmlcml.cmlimpl.AbstractCMLDocumentImpl.<init>(AbstractCMLDocumentImpl.java:56) > > This one is a problem with a conflict between the cmlCore.jar in CDK, and the > GNUJAXP (I think) in Debian... I tried it, but I can't reproduce the error. The application saves the CML without error-messages. Do you tried it on an up-to-date Debian Sid? Can you please control the symlinks in the directory /usr/share/libcdk-java/lib? Which Java-Version do you use? There is an alternative to libgnujaxp-java, I think. I can try to use libjaxp1.2-java instead of libgnujaxp-java. Regards, Daniel -- |
From: Daniel L. <dan...@gm...> - 2004-08-09 17:49:30
|
Daniel Leidert wrote: > Am Mo, den 09.08.2004 schrieb E.L. Willighagen um 9:20: > > 2. When saving CML I get this error: > > java.lang.VerifyError: (class: gnu/xml/pipeline/DomConsumer$Handler, method: > > startDocument signature: ()V) Illegal use of nonvirtual function call > > at gnu.xml.pipeline.DomConsumer.<init>(DomConsumer.java:115) > > at gnu.xml.dom.Consumer.<init>(Consumer.java) > > at gnu.xml.dom.JAXPFactory$JAXPBuilder.<init>(JAXPFactory.java:131) > > at gnu.xml.dom.JAXPFactory.newDocumentBuilder(JAXPFactory.java:96) > > at > > uk.co.demon.ursus.dom.pmr.PMRDocumentImpl.<init>(PMRDocumentImpl.java:62) > > at > > org.xmlcml.cmlimpl.AbstractCMLDocumentImpl.<init>(AbstractCMLDocumentImpl.java:56) > > > > This one is a problem with a conflict between the cmlCore.jar in CDK, and the > > GNUJAXP (I think) in Debian... [..] > There is an alternative to libgnujaxp-java, I think. I can try to use > libjaxp1.2-java instead of libgnujaxp-java. I build a jchempaint-package, which uses libjaxp1.2-java instead of libgnujaxp-java. Can you test it, if the error still appears? You can get it from my repository: deb http://www.wgdd.de/debarchiv unstable contrib non-free Or for manual download: http://www.wgdd.de/cgi-bin/sitexplorer.cgi?/debarchiv/dists/unstable/contrib/binary-i386/ Regards, Daniel -- |
From: E.L. W. <eg...@sc...> - 2004-08-11 06:03:42
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 August 2004 11:17, Daniel Leidert wrote: > Am Mo, den 09.08.2004 schrieb E.L. Willighagen um 9:20: > > On Monday 09 August 2004 08:55, E.L. Willighagen wrote: > > > > It's also online. This version was built with runtime-dependencies > > > > and includes the jcpapplet.jar. It seems to work correct. > > > > > > I'll try them now... > > > > Ok, the Packages.gz does not seem updated yet, so I had to manually get > > the packages... I've found some issues... but before I post them, I wou= ld > > like to ask you (Daniel), wether you plan to support these packages or > > not? > > I will support them.=20 Excellent! > If you want to contact me, please use the email-address, given by the > packages.=20 Ok. > > If so, > > we should get you an SF account, so that you can get package bugs > > assigned, and maybe put the packaging stuff in CVS... What are your > > thoughts on that? > > Ok. Did you get an SF account yet? > > Here are the two problems I found with the Debian package of > > JChemPaint... > > > > 1. The application starts with no problem, but the DirBrowser plugin is > > not available from the plugin menu... it should be in the tar.gz plugin/ > > Yes, I found the problem. The dir-variable in <target id=3D"old-jar" ..> > was not right. This is fixed, a new version is uploaded to mentors. You told me a non-mentors download, but got that email at home... -3 on=20 mentors seems to work now... I also saw the libcdk-java-plugins package! Excellent! But how do you make= =20 those? There are no source tar.gz packages for them (maybe there ought to=20 be...) A few comments:=20 1. I hope you saw the new plugin page.=20 2. maybe the package should be split up to have one package for each plugin= =2E..=20 e.g. cotviewer is only really interesting for JCP/CDK developers, and more= =20 plugins will be released on the next months... another problem with having= =20 one package is that the version number does not match the version of the=20 plugin... another advantage of seperate packages for the plugins, would be that e.g. Jmol could Suggest: plugins that really work... 3. the README mentions users to have to make a symbolic link or copy the=20 files... my actual intention was to have a global plugin dir for Jmol and=20 JChemPaint, e.g. /usr/share/libcdk-java/plugin :) I'll work on some patches upstream :) > > 2. When saving CML I get this error: > > java.lang.VerifyError: (class: gnu/xml/pipeline/DomConsumer$Handler, > > method: startDocument signature: ()V) Illegal use of nonvirtual function > > call at gnu.xml.pipeline.DomConsumer.<init>(DomConsumer.java:115) at > > gnu.xml.dom.Consumer.<init>(Consumer.java) > > at > > gnu.xml.dom.JAXPFactory$JAXPBuilder.<init>(JAXPFactory.java:131) at > > gnu.xml.dom.JAXPFactory.newDocumentBuilder(JAXPFactory.java:96) at > > uk.co.demon.ursus.dom.pmr.PMRDocumentImpl.<init>(PMRDocumentImpl.java:6= 2) > > at > > org.xmlcml.cmlimpl.AbstractCMLDocumentImpl.<init>(AbstractCMLDocumentIm= pl > >.java:56) > > > > This one is a problem with a conflict between the cmlCore.jar in CDK, a= nd > > the GNUJAXP (I think) in Debian... > > I tried it, but I can't reproduce the error. The application saves the > CML without error-messages. Do you tried it on an up-to-date Debian Sid? > Can you please control the symlinks in the directory > /usr/share/libcdk-java/lib? Which Java-Version do you use? > > There is an alternative to libgnujaxp-java, I think. I can try to use > libjaxp1.2-java instead of libgnujaxp-java. This seems fixed in the latest JChemPaint package... thanx! 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) iD8DBQFBGbazd9R8I9Yza6YRAu0eAJ9w9jhdPTaIlLalTikmts+HIjcJSwCfVMuU c1RMDCdbfZYCK7kQ5o0qKao=3D =3DwJ9W =2D----END PGP SIGNATURE----- |
From: E.L. W. <eg...@sc...> - 2004-08-11 06:25:25
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 August 2004 08:03, E.L. Willighagen wrote: > A few comments: 4. I noted that the shell wrapper (jmol and jchempaint) do not pass on=20 parameters. The last lines should end with '$*' as in: $command -jar /usr/share/java/jmol.jar $* So that one can do 'jmol --help' 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) iD8DBQFBGbvNd9R8I9Yza6YRAvYWAJ4udKFvB/NQc/HINu3okb2Fv8hnTgCgqjs7 lt2YQfrcxEEQPPIj67CC9CM=3D =3D1q5r =2D----END PGP SIGNATURE----- |
From: E.L. W. <eg...@sc...> - 2004-08-11 06:30:04
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 August 2004 08:03, E.L. Willighagen wrote: > 3. the README mentions users to have to make a symbolic link or copy the > files... my actual intention was to have a global plugin dir for Jmol and > JChemPaint, e.g. /usr/share/libcdk-java/plugin :) I'll work on some patch= es > upstream :) Seem to already have done this for JChemPaint... please add this to shell=20 wrapper: $command -Dplugin.dir=3D/usr/share/libcdk-java/plugins=20 =2D -jar /usr/share/java/jchempaint.jar $* 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) iD8DBQFBGbzcd9R8I9Yza6YRAp2yAKCrAIMkKA6X2IFQwExoHapucLviCwCfeIld jHtgrLpaAVR8vRc/BMtiFEw=3D =3Dir+j =2D----END PGP SIGNATURE----- |
From: E.L. W. <eg...@us...> - 2004-08-25 10:19:26
Attachments:
globalPluginDir.patch
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 August 2004 08:29, E.L. Willighagen wrote: > On Wednesday 11 August 2004 08:03, E.L. Willighagen wrote: > > 3. the README mentions users to have to make a symbolic link or copy the > > files... my actual intention was to have a global plugin dir for Jmol a= nd > > JChemPaint, e.g. /usr/share/libcdk-java/plugin :) I'll work on some > > patches upstream :) > > Seem to already have done this for JChemPaint... please add this to shell > wrapper: > > $command -Dplugin.dir=3D/usr/share/libcdk-java/plugins > -jar /usr/share/java/jchempaint.jar $* Daniel, I forgot to apply your suggestion about this thingy to CVS before the 2.0.5= releas... it will be part of the next release, but not sure when that will= be released... The patch is attached, so maybe you can add it for now to the Debian packag= e? Egon =2D --=20 eg...@us... =2D --------------------------------------- CDK: http://cdk.sf.net/ JChemPaint: http://jchempaint.sf.net/ Jmol: http://www.jmol.org/ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFBLGeWd9R8I9Yza6YRAuGVAKC0YUO3tXc9ueVrRet6ibwIrADlyACfYb07 XCrzA2vmXU6v9vbkSmFosN0=3D =3DWOvs =2D----END PGP SIGNATURE----- |
From: Daniel L. <dan...@gm...> - 2004-08-11 21:19:05
|
E.L. Willighagen wrote: > On Monday 09 August 2004 11:17, Daniel Leidert wrote: > > Am Mo, den 09.08.2004 schrieb E.L. Willighagen um 9:20: > > > On Monday 09 August 2004 08:55, E.L. Willighagen wrote: > > > If so, > > > we should get you an SF account, so that you can get package bugs > > > assigned, and maybe put the packaging stuff in CVS... What are your > > > thoughts on that? > > > > Ok. > > Did you get an SF account yet? This will still need a month or two. > > > Here are the two problems I found with the Debian package of > > > JChemPaint... > > > > > > 1. The application starts with no problem, but the DirBrowser plugin is > > > not available from the plugin menu... it should be in the tar.gz plugin/ > > > > Yes, I found the problem. The dir-variable in <target id="old-jar" ..> > > was not right. This is fixed, a new version is uploaded to mentors. > > You told me a non-mentors download, but got that email at home... -3 on > mentors seems to work now... -3 on mentors still uses libgnujaxp-java, not libjaxp1.2-java. > 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. > A few comments: > 1. I hope you saw the new plugin page. Yes, I saw it. BTW: On http://cdk.sourceforge.net/plugin-rssviewer.html you still link to http://wwmm.ch.cam.ac.uk/moinadmin/CmlRssFeeds. > 2. maybe the package should be split up to have one package for each plugin... > e.g. cotviewer is only really interesting for JCP/CDK developers, and more > plugins will be released on the next months... another problem with having > one package is that the version number does not match the version of the > plugin... I noticed this. The package will be split in the future. This package was only the first for testing. > 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. BTW: I tried dirbrowser and rssviewer with the jmol.jar from the Jmol10pre12-release. They both gave error-messages. But I don't know, if this is normal, because I built the plugins against debian-libraries and the last released cdk-version. But if you are interested, I can send you the log-files. > 3. the README mentions users to have to make a symbolic link or copy the > files... my actual intention was to have a global plugin 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=/usr/share/libcdk-java/plugin is set as command-line parameter. 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. Maybe 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. > > > 2. When saving CML I get this error: > > > [..] > > I tried it, but I can't reproduce the error. The application saves the > > CML without error-messages. Do you tried it on an up-to-date Debian Sid? > > Can you please control the symlinks in the directory > > /usr/share/libcdk-java/lib? Which Java-Version do you use? > > > > There is an alternative to libgnujaxp-java, I think. I can try to use > > libjaxp1.2-java instead of libgnujaxp-java. > > This seems fixed in the latest JChemPaint package... thanx! The packages at mentors use libgnujaxp-java. I only made a test-build against libjaxp1.2-java, which is located in my repository. So, I don't know, why you get this error. Nothing has changed. PS: I found some bugs/problems in the plugins. (1) wwmmplugin It seems, that the import path is not correct. I think, it should be: src/uk/ac/cam/ch/wwmm/WWMMCDKPluginQueryFrame.java (line 40,41,43) import org.openscience.cdk.config.AtomTypeFactory; import org.openscience.cdk.tools.manipulator.ChemModelManipulator; import org.openscience.cdk.geometry.Projector; src/uk/ac/cam/ch/wwmm/WWMMCDKPlugin.java (line 22) import org.openscience.cdk.tools.manipulator.ChemModelManipulator; (2) isotropicshielding-plugin The same problem. I think, it should be: src/org/openscience/cdkplugin/isotropicshielding/IsotropicShieldingPlugin.java (line 59,60) import org.openscience.cdk.tools.manipulator.ChemFileManipulator; import org.openscience.cdk.tools.manipulator.ChemModelManipulator; But then, compiling still stops with an error: classes: [javac] Compiling 4 source files to build/classes [javac] src/org/openscience/cdkplugin/isotropicshielding/IsotropicShieldingPlugin.java:551: missing return statement [javac] } [javac] ^ [javac] 1 error I don't know, what the compiler is missing. Regards, Daniel -- |
From: Egon W. <eg...@us...> - 2004-08-12 07:35:13
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 August 2004 23:20, Daniel Leidert wrote: > E.L. Willighagen wrote: > > On Monday 09 August 2004 11:17, Daniel Leidert wrote: > > > Am Mo, den 09.08.2004 schrieb E.L. Willighagen um 9:20: > > > > On Monday 09 August 2004 08:55, E.L. Willighagen wrote: > > > > If so, > > > > we should get you an SF account, so that you can get package bugs > > > > assigned, and maybe put the packaging stuff in CVS... What are your > > > > thoughts on that? > > > > > > Ok. > > > > Did you get an SF account yet? > > This will still need a month or two. Huh? I can imagine that a project takes a month or two... but a user accoun= t? > > > > Here are the two problems I found with the Debian package of > > > > JChemPaint... > > > > > > > > 1. The application starts with no problem, but the DirBrowser plugin > > > > is not available from the plugin menu... it should be in the tar.gz > > > > plugin/ > > > > > > Yes, I found the problem. The dir-variable in <target id=3D"old-jar" = =2E.> > > > was not right. This is fixed, a new version is uploaded to mentors. > > > > You told me a non-mentors download, but got that email at home... -3 on > > mentors seems to work now... > > -3 on mentors still uses libgnujaxp-java, not libjaxp1.2-java. Mmmm... well, maybe the problem was different then... last time I tried the= =20 problem was solved... > > 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. makin= g a=20 deb package from CVS... > > A few comments: > > 1. I hope you saw the new plugin page. > > Yes, I saw it. > > BTW: On http://cdk.sourceforge.net/plugin-rssviewer.html you still link > to http://wwmm.ch.cam.ac.uk/moinadmin/CmlRssFeeds. That page should have been deleted... I updated the website sources in CVS,= =20 but forgot to delete the pages from the webserver...=20 > > 2. maybe the package should be split up to have one package for each > > plugin... e.g. cotviewer is only really interesting for JCP/CDK > > developers, and more plugins will be released on the next months... > > another problem with having one package is that the version number does > > not match the version of the plugin... > > I noticed this. The package will be split in the future. This package > was only the first for testing. I hope you don't take these comments as complaints... they aren't. I=20 appreciate very much what you're doing... > > 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=20 stopped since we are focusing on the 10 release... > BTW: I tried dirbrowser and rssviewer with the jmol.jar from the > Jmol10pre12-release. They both gave error-messages. But I don't know, if > this is normal, because I built the plugins against debian-libraries and > the last released cdk-version. But if you are interested, I can send you > the log-files. I normally build the plugins from CVS against CDK from CVS... And test them with a released JCP/Jmol version... well, I try... :) Ok, I will have to ta= ke=20 more care here... for now, you can best build against a recent CDK CVS=20 checkout... > > 3. the README mentions users to have to make a symbolic link or copy the > > files... my actual intention was to have a global plugin dir for Jmol a= nd > > 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-line > parameter.=20 Is there a special reason why you overwrite the options of the jar file=20 itself? > So every user can still choose, which plugin(s), he want to=20 > 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. Maybe 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, i= t's reasonable standard, but it needs to work with other platforms too, hence t= he=20 current implementation... > > > > 2. When saving CML I get this error: > > > > [..] > > > > > > I tried it, but I can't reproduce the error. The application saves the > > > CML without error-messages. Do you tried it on an up-to-date Debian > > > Sid? Can you please control the symlinks in the directory > > > /usr/share/libcdk-java/lib? Which Java-Version do you use? > > > > > > There is an alternative to libgnujaxp-java, I think. I can try to use > > > libjaxp1.2-java instead of libgnujaxp-java. > > > > This seems fixed in the latest JChemPaint package... thanx! > > The packages at mentors use libgnujaxp-java. I only made a test-build > against libjaxp1.2-java, which is located in my repository. So, I don't > know, why you get this error. Nothing has changed. > > PS: I found some bugs/problems in the plugins. > > (1) wwmmplugin > It seems, that the import path is not correct. I think, it should be: > src/uk/ac/cam/ch/wwmm/WWMMCDKPluginQueryFrame.java (line 40,41,43) > import org.openscience.cdk.config.AtomTypeFactory; > import org.openscience.cdk.tools.manipulator.ChemModelManipulator; > import org.openscience.cdk.geometry.Projector; > src/uk/ac/cam/ch/wwmm/WWMMCDKPlugin.java (line 22) > import org.openscience.cdk.tools.manipulator.ChemModelManipulator; YY, please take notice of the above... > (2) isotropicshielding-plugin > The same problem. I think, it should be: > src/org/openscience/cdkplugin/isotropicshielding/IsotropicShieldingPlugin= =2Ej >ava (line 59,60) import > org.openscience.cdk.tools.manipulator.ChemFileManipulator; > import org.openscience.cdk.tools.manipulator.ChemModelManipulator; > > But then, compiling still stops with an error: > classes: > [javac] Compiling 4 source files to build/classes > [javac] > src/org/openscience/cdkplugin/isotropicshielding/IsotropicShieldingPlugin= =2Ej >ava:551: missing return statement [javac] } > [javac] ^ > [javac] 1 error Christoph, can you look at this? Egon =2D --=20 eg...@us... GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBGx2od9R8I9Yza6YRAgkWAKDAX9bHU0g99/TOyBF6+itdxfx6YgCgm4Ct w14mX/qrPPppb5D5VYcNJMk=3D =3D7jwS =2D----END PGP SIGNATURE----- |
From: Daniel L. <dan...@gm...> - 2004-08-12 09:29:26
|
Egon Willighagen wrote > On Wednesday 11 August 2004 23:20, Daniel Leidert wrote: > > E.L. Willighagen wrote: > > > Did you get an SF account yet? > > > > This will still need a month or two. > > Huh? I can imagine that a project takes a month or two... but a user account? No, a joke. I was waiting. Now I have an account. Which information do you need? > > > 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 ...). > > > 2. maybe the package should be split up to have one package for each > > > plugin... e.g. cotviewer is only really interesting for JCP/CDK > > > developers, and more plugins will be released on the next months... > > > another problem with having one package is that the version number does > > > not match the version of the plugin... > > > > I noticed this. The package will be split in the future. This package > > was only the first for testing. > > I hope you don't take these comments as complaints... they aren't. I don't. Don't care :-) > I appreciate very much what you're doing... Then I hope you like the new packages (libcdk-java-dirbrowser0.8, libcdk-java-rssviewer0.12, ..). I made also a package for the wwmm-plugin. But I'm not sure, if this is a contrib- or a non-free-package (I can't classify the artistic license). It is not uploaded. > > > 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 >= -3 (tested). Dito for the macieplugin. rssviewer is definitely not working with jmol-9. > > > 3. the README mentions users to have to make a symbolic link or copy the > > > files... my actual intention was to have a global plugin 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=/usr/share/libcdk-java/plugin is set as command-line > > parameter. > > Is there a special reason why you overwrite the options of the jar file > itself? I don't know, what you mean(?). > > 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. Maybe 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-path 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). Regards, Daniel -- |
From: Egon W. <eg...@us...> - 2004-08-12 09:57:20
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 August 2004 11:30, Daniel Leidert wrote: > Egon Willighagen wrote > > > On Wednesday 11 August 2004 23:20, Daniel Leidert wrote: > > > E.L. Willighagen wrote: > > > > Did you get an SF account yet? > > > > > > This will still need a month or two. > > > > Huh? I can imagine that a project takes a month or two... but a user > > account? > > No, a joke. I was waiting. Now I have an account. Which information do > you need? :) I just need you account name... I can then add you to the Jmol/JChemPaint/C= DK=20 project so that you can add stuff to create the packages to CVS... (and=20 overwrite existing stuff in some cases) > > > > I also saw the libcdk-java-plugins package! Excellent! But how do y= ou > > > > make those? There are no source tar.gz packages for them (maybe the= re > > > > 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? > > I appreciate very much what you're doing... > > Then I hope you like the new packages (libcdk-java-dirbrowser0.8, > libcdk-java-rssviewer0.12, ..).=20 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? > I made also a package for the=20 > wwmm-plugin. But I'm not sure, if this is a contrib- or a > non-free-package (I can't classify the artistic license). It is not > uploaded. I'll ask around... > > > > 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 actual= ly > > 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.=20 Excellent! > rssviewer is definitely not working with jmol-9.=20 Ok, I'll see if I can do something about that... > > > > 3. the README mentions users to have to make a symbolic link or copy > > > > the files... my actual intention was to have a global plugin 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-line > > > 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? 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= =20 application? > > > 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. Maybe 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 Linu= x, > > 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-path > 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 distribu= te=20 binaries, i.e. they would need to make a separate binary for each platform,= =20 and the nice thing if Java is that that is not required... What we could do, is create a class which would figure out on which platfor= m=20 it is running, and set an appropriate path... Such a class might be usefull in other cases too... I think it could work a= =20 bit like this: we would need one class which would identify the recognized platforms: Platform.WIN32 Platform.MACOSX Platform.POSIX etc which this API: Platform.getName() Platform.getVersion() Platform.equals(Platform) Platform.hashcode() (or so...) Anyway, other classes could then do things like if (platform.equals(Platform.WIN98) { pluginDir =3D "C:\Program Files\CDK\Plugins"; // but then a bit better... } Egon =2D --=20 eg...@us... GPG: 1024D/D6336BA6 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBGz73d9R8I9Yza6YRAgYiAJoD6bjpW6i6XWaH27o+hAA0mELfiwCdGyw4 vAW/DM5l/DjLti8mDyFgYEg=3D =3DWhyb =2D----END PGP SIGNATURE----- |
From: Daniel L. <dan...@gm...> - 2004-08-12 11:25:39
|
Egon Willighagen wrote: > On Thursday 12 August 2004 11:30, Daniel Leidert wrote: > > Egon Willighagen wrote > > > > > On Wednesday 11 August 2004 23:20, Daniel Leidert wrote: > > > > E.L. Willighagen wrote: > > > > > Did you get an SF account yet? > > > > > > > > This will still need a month or two. > > > > > > Huh? I can imagine that a project takes a month or two... but a user > > > account? > > > > No, a joke. I was waiting. Now I have an account. Which information do > > you need? > > :) > > I just need you account name... I can then add you to the Jmol/JChemPaint/CDK > project so that you can add stuff to create the packages to CVS... (and > overwrite existing stuff in some cases) The account-name is "dleidert". > > > > > 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. > > > 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 > > > > > 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 >= -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. > > > > > 3. the README mentions users to have to make a symbolic link or copy > > > > > the files... my actual intention was to have a global plugin 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=/usr/share/libcdk-java/plugin is set as command-line > > > > 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=/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. > 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. Maybe 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-path > > 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... 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". > What we could do, is create a class which would figure out on which platform > it is running, and set an appropriate path... > > Such a class might be usefull in other cases too... I think it could work a > bit like this: we would need one class which would identify the recognized > platforms: > > Platform.WIN32 > Platform.MACOSX > Platform.POSIX > > etc > > which this API: > > Platform.getName() > Platform.getVersion() > Platform.equals(Platform) > Platform.hashcode() > > (or so...) > > Anyway, other classes could then do things like > > if (platform.equals(Platform.WIN98) { > pluginDir = "C:\Program Files\CDK\Plugins"; // but then a bit better... > } This is also a possibility, but maybe overkill(?). Regards, Daniel -- |
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----- |
From: E.L. W. <E.W...@sc...> - 2004-08-12 15:01:18
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 12 August 2004 13:26, Daniel Leidert wrote: > > I just need you account name... I can then add you to the > > Jmol/JChemPaint/CDK project so that you can add stuff to create the > > packages to CVS... (and overwrite existing stuff in some cases) > > The account-name is "dleidert". I've added you as 'Packager' to Jmol, JChemPaint and CDK. About Jmol: The v9 stuff is in the b6 branch. The debian files in packaging/debian. About JChemPaint: The module is JCPCDK. The deb files are in packages/debian. About CDK: The deb files are in packages/debian/cdk. But you might have seen that already... Egon =2D --=20 E.W...@sc... PhD on Molecular Representation in Chemometrics Radboud University, Nijmegen http://www.cac.sci.ru.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) iD8DBQFBG4Ywd9R8I9Yza6YRApODAJ9Q1vbvQCptaR2g8zIfkT+Fw2K/RgCgrFlH KrSuhUHg1/oKXNfeIYKzLaM=3D =3DtVPP =2D----END PGP SIGNATURE----- |