[Cdk-devel] Re: [Jchempaint-devel] Re: new Debian-packages for jmol and jchempaint

[Daniel L. <dan...@gm...>]

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
--