>
>
> - All jars are enumerated with their full file name incl. version info.
> This will break when the jars are updated.
> I wrote chk_spreadsheet_support.m in such a way that version info in the
> name of the jar is ignored.
>
I thought that if specific jars versions are desired for a specific version
of the io package (such as in the case of xercesImpl-2.9.1), the io's
PKG_ADD can search for the desired version.
Assume that after a user has installed the tree and after a while you have
updated the io package such that a newer version of a jar is required, the
newer PKG_ADD will look for the updated version. If your
chk_spreadsheet_support already checks for the compatibility with founded
jars from the jars content, than I agree that including the versions in the
name is redundant.
>
> - Like Benjamin, you've put the jars in /bin. Benjamin did this (had to do
> this) because he invoked file_in_path(), that has no knowledge of /lib
> I'd rather have the jars in /lib. After all, the jars are Java libraries,
> not executables (yeah I know about the .dlls in /bin).
> The location of /lib can easily be found using
> libdir = octave_config_info ("libdir")
>
>
Currently, at least with the current installation tree, the lib subdir
includes:
a. Libraries to link with when when using mkoctfile from within octave (some
pkconfig files are also included).
For that reason (mkoctfile) this dir is set by -L option by the LDFLAGS env.
var. as the directory in which libraries to link with reside.
b. The octave lib sub dir as generated by the build process.
I am not an expert of how to construct the tree, I have just followed
Benjamin's conventions. If I will simply put the jars in the lib subdir,
they will mix with the libraries to link with !
- Why did you include chk_spreadsheet_support() in a for...end loop?
> AFAICS, all you need to do is to check for a loaded Java package, and if
> loaded, call chk_spreadsheet_support ('/path/to/jars').
> chk_spreadsheet_support itself will then sort it all out: search for the
> needed jars there and add the ones it found to the classpath.
>
>
I have tried to do it in a more general way such that jars may reside in a
set of directories (not all of them in a single place) abd the file_in_path
founds the specific path for each jar in a loop.
If you assume that all the jars are in a single directory, you are right -
giving a single dir name as an input to chk_spreadsheet_support does it
all.
I've attached a revised PKG_ADD (for io package). It works for me.
> Will you (in turn) check if you agree with it, please?
>
It is OK, assuming that all jars are located in a single known place. I
would suggest may be that you will enhance chk_spreadsheet_support to get as
input a search path (several delimited paths) rather than a single path (you
can also utilize file_in_path for such searching), this will make the io
package more 'robust' to different installations and platforms. I have no
experience with installations and directories on other platforms, and the
PKG_ADD should be general enough to properly do the job for most of them.
Also, I would add a respective PKD_DEL that will remove the jars paths from
the java package if the io package is unloaded.
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
