Nit Nit wrote:
>
> - 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.
While in principle you are right, the xercesImpl.jar issue put you on
the wrong foot. (I have to look into this issue later, I got no time now.)
First of all, coping with different .jar versions, if at all needed, is
done in the low-level spreadsheet m-files. No need to repeat that elsewhere.
If a newer jar gets to be supported, the io package gets an update, in
next versions including PKG_ADD / PKG_DEL.
If some .jar version is not (yet, or no more) supported, then that is
simply too bad.
IMO it is clearly indicated which .jar versions are supported.
FYI, ODF Toolkit (the one that requires xerces) is at version 0.8.7,
it's API is still fairly unstable. It is the only spreadsheet interface
for which I had to add in separate functions for individual odfdom.jar
versions.
All other spreadsheet interfaces are backward compatible up till now.
So all in all, having to keep track of .jar versions using PKG_ADD etc.
is simply not needed and in fact unwanted as it only duplicates stuff.
<snip>
> - 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.
The msys shell (in which MinGW Octave runs) mimics the FHS
(http://www.pathname.com/fhs/) in many ways, save for some
simplifications (e.g., /usr/lib hard-linked (?) to /lib). I'd rather
leave that intact as much as possible.
Indeed, on my Linux systems, Mandriva-supplied .jar files also reside in
/usr/lib
> 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 !
How then? Loaders only touch libraries they need, not all libraries in a
given directory.
But OK, to make things more clear we could put the io .jars in a /lib
subdir, I suggest /lib/java as that is what I often encounter in other
SW and systems.
Would that suit you better?
> - 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.
If each .jar resides in a separate directory, it is much easier to add
them to the classpath by hand and avoid chk_spreadsheet_support completely.
While I'm not a Matlab fanboi, I think their solution of keeping all
jars together in the $matlabroot/java subdir (somewhat sorted into
internal and external jars) is a good one.
> 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.
Putting all jars in one place makes things simple and tractable. I love
simplicity. IMO Octave's setup is complicated enough already.
> Also, I would add a respective PKD_DEL that will remove the jars paths
> from the java package if the io package is unloaded.
Yep, I haven't thought of that. I'll look into it.
Thank you Nitzan.
Philip
------------------------------------------------------------------------------
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
