Main.BinaryDistribution History
Hide minor edits - Show changes to output
Changed lines 20-31 from:
If a native library is loaded by its absolute path, a problem arises when it is linked against other libraries that are not in the system search path.
On
Onlibries in the same folder. Let's assume we have a Java library A.jar which loads native library foo, which itself depends on library bar.
On Linux, the --rpath options of the linker allows to add arbitrary folders to the runtime linker search path. In order to add the path of the native library, the special @@$ORIGIN@@ can be used when linking foo. When foo is loaded, dependent libraries are searched in the same folder as foo.
On Mac OS X, a similar behavior is achieved by using @loader_path/bar.dylib as the install_name of library bar. When linking foo againstbar, the install_name of bar is stored in foo. When foo is loaded, @loader_path is set to foo's folder, and bar can be found in the same folder.
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is [[libxine-java.ringwald.ch/files/NativeLibExample.tar.gz |here]].
On
On
On Linux, the --rpath options of the linker allows to add arbitrary folders to
On Mac OS X, a similar behavior is achieved by using @loader_path/bar.dylib as the install_name of library bar. When linking foo against
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is [[libxine-java.ringwald.ch/files/NativeLibExample.tar.gz |here]]
to:
If a native library is loaded by its absolute path, a problem arises when it is linked against other libraries that are not in the system search path. On Windows, the folder of the native library is automatically added to the search path for dependent libraries. There, if all native libraries are in the same folder, the runtime loader can find and load all libraries correctly. On Linux and Mac OS X, however, extra care has to be taken to allow for dependent libraries that are placed in the same folder as the native library. Let's assume we have a Java library A.jar which loads native library foo, which itself depends on library bar.
* On Linux, the --rpath options of the linker allows to add arbitrary folders to the runtime linker search path. In order to add the path of the native library, the special @@$ORIGIN@@ can be used when linking foo. When foo is loaded, dependent libraries are searched in the same folder as foo.
* On Mac OS X, a similar behavior is achieved by using @loader_path/bar.dylib as the install_name of library bar. When linking foo against bar, the install_name of bar is stored in foo. When foo is loaded, @loader_path is set to foo's folder, and bar can be found in the same folder.
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is [[http://libxine-java.ringwald.ch/files/NativeLibExample.tar.gz | here]].
* On Linux, the --rpath options of the linker allows to add arbitrary folders to the runtime linker search path. In order to add the path of the native library, the special @@$ORIGIN@@ can be used when linking foo. When foo is loaded, dependent libraries are searched in the same folder as foo.
* On Mac OS X, a similar behavior is achieved by using @loader_path/bar.dylib as the install_name of library bar. When linking foo against bar, the install_name of bar is stored in foo. When foo is loaded, @loader_path is set to foo's folder, and bar can be found in the same folder.
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is [[http://libxine-java.ringwald.ch/files/NativeLibExample.tar.gz | here]].
Changed lines 30-31 from:
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is here.
to:
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is [[libxine-java.ringwald.ch/files/NativeLibExample.tar.gz |here]].
Changed lines 26-27 from:
On Linux,
to:
On Linux, the --rpath options of the linker allows to add arbitrary folders to the runtime linker search path. In order to add the path of the native library, the special @@$ORIGIN@@ can be used when linking foo. When foo is loaded, dependent libraries are searched in the same folder as foo.
On Mac OS X, a similar behavior is achieved by using @loader_path/bar.dylib as the install_name of library bar. When linking foo against bar, the install_name of bar is stored in foo. When foo is loaded, @loader_path is set to foo's folder, and bar can be found in the same folder.
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is here.
On Mac OS X, a similar behavior is achieved by using @loader_path/bar.dylib as the install_name of library bar. When linking foo against bar, the install_name of bar is stored in foo. When foo is loaded, @loader_path is set to foo's folder, and bar can be found in the same folder.
An example project with a dummy library that searches for its JAR in the classpath to find its native libraries automatically is here.
Changed lines 17-18 from:
* ''Self Inspection'': A variation of the last approach is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
to:
* ''Self Inspection'': Instead of specifying the path to the native libraries at the Java VM invokation, a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
!!! JNI and dependent libraries
If a native library is loaded by its absolute path, a problem arises when it is linked against other libraries that are not in the system search path.
On Windows, the of the native library is automatically added to the search path for dependent libraries. There, if all native libraries are in the same folder, the runtime can find and load all libraries correctly.
On Linux and Mac OS X, however, extra care has to be taken to allow for dependent libries in the same folder. Let's assume we have a Java library A.jar which loads native library foo, which itself depends on library bar.
On Linux,
!!! JNI and dependent libraries
If a native library is loaded by its absolute path, a problem arises when it is linked against other libraries that are not in the system search path.
On Windows, the of the native library is automatically added to the search path for dependent libraries. There, if all native libraries are in the same folder, the runtime can find and load all libraries correctly.
On Linux and Mac OS X, however, extra care has to be taken to allow for dependent libries in the same folder. Let's assume we have a Java library A.jar which loads native library foo, which itself depends on library bar.
On Linux,
Changed lines 27-28 from:
Building all the dependent libraries manually would be a tedious task. With a bit of luck, the efforts of the VideoLan team to automatically build all libraries can be directly harvested. xine and vlc most likely share most of their dependent libraries. Have a look at the very helpful/detailed [[http://git.videolan.org/?p=vlc.git;a=history;f=extras/contrib;hb=HEAD| GIT contrib changelog]] and the [[ftp://ftp.videolan.org/pub/videolan/testing/contrib/ |binary contrib packages for OS X Intel/PPC and Win32]].
to:
Building all the dependent libraries manually would be a tedious task. With a bit of luck, the efforts of the VideoLan team to automatically build all libraries can be directly harvested. xine and vlc most likely share most of their dependent libraries. Have a look at the very helpful/detailed [[http://git.videolan.org/?p=vlc.git;a=history;f=extras/contrib;hb=HEAD| GIT changelog for extras/contrib]] and the [[ftp://ftp.videolan.org/pub/videolan/testing/contrib/ |binary contrib packages for OS X Intel/PPC and Win32]].
Changed lines 27-29 from:
Building all the dependent libraries manually would be a tedious task. With a bit of luck, the efforts of the VideoLan team to automatically build all libraries can be directly harvested. xine and vlc most likely share most of their dependent libraries. See extras/contrib of VLC.
See also[[ftp://ftp.videolan.org/pub/videolan/testing/contrib/]] and the very helpful/detailed [[http://git.videolan.org/?p=vlc.git;a=history;f=extras/contrib;hb=HEAD| GIT contrib changelog]]
See also
to:
Building all the dependent libraries manually would be a tedious task. With a bit of luck, the efforts of the VideoLan team to automatically build all libraries can be directly harvested. xine and vlc most likely share most of their dependent libraries. Have a look at the very helpful/detailed [[http://git.videolan.org/?p=vlc.git;a=history;f=extras/contrib;hb=HEAD| GIT contrib changelog]] and the [[ftp://ftp.videolan.org/pub/videolan/testing/contrib/ |binary contrib packages for OS X Intel/PPC and Win32]].
Changed lines 28-29 from:
See also [[ftp://ftp.videolan.org/pub/videolan/testing/contrib/]]
to:
See also [[ftp://ftp.videolan.org/pub/videolan/testing/contrib/]] and the very helpful/detailed [[http://git.videolan.org/?p=vlc.git;a=history;f=extras/contrib;hb=HEAD| GIT contrib changelog]]
Changed lines 28-29 from:
to:
See also [[ftp://ftp.videolan.org/pub/videolan/testing/contrib/]]
Added lines 26-28:
!!! How to build all the required libraries?
Building all the dependent libraries manually would be a tedious task. With a bit of luck, the efforts of the VideoLan team to automatically build all libraries can be directly harvested. xine and vlc most likely share most of their dependent libraries. See extras/contrib of VLC.
Building all the dependent libraries manually would be a tedious task. With a bit of luck, the efforts of the VideoLan team to automatically build all libraries can be directly harvested. xine and vlc most likely share most of their dependent libraries. See extras/contrib of VLC.
Changed lines 5-6 from:
!!! Loading Native Libraries in Java
to:
!!! Loading native libraries in Java
Changed lines 19-20 from:
!!! What should be in the Package?
to:
!!! What should be in the package?
Changed lines 26-27 from:
!!! Software Distribution
to:
!!! Software distribution
Changed lines 33-34 from:
!!! Will it Work on the Web?
to:
!!! Will it work on the web?
Changed lines 37-38 from:
!!! The libxine-java Plan
to:
!!! The libxine-java plan
Added lines 3-4:
!!! Loading Native Libraries in Java
Changed lines 17-18 from:
to:
!!! What should be in the Package?
Added lines 24-25:
!!! Software Distribution
Changed line 27 from:
* On Mac OS X, a GUI-application consists of a folder (named ApplicationName.app), which contains everything required. All JARs and native libs can be placed inside this folder. The folder can then be downloaded as a ZIP archive or a DMG disk image.
to:
* On Mac OS X, a GUI-application consists of a folder (named ApplicationName.app), which contains everything required. All JARs and native libraries can be placed inside this folder. The folder can then be downloaded as a ZIP archive or a DMG disk image.
Added lines 31-32:
!!! Will it Work on the Web?
Added lines 35-36:
!!! The libxine-java Plan
Changed lines 26-29 from:
In addition to these, Java Web Start allows to store all JARs and other resources, including native libraries, on a web server, and just specify the corresponding URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib). libxine-java shouldcheck the classpath to find this folder and load all required libraries from there. By this, all scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provide by Java Web Start is not clear to me yet.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib). libxine-java should
to:
In addition to these, [[http://en.wikipedia.org/wiki/Java_web_start|Java Web Start]] allows to store all JARs and other resources, including native libraries, on a web server, and just specify the corresponding URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib). libxine-java should use the ''Self Inspection'' to check the classpath and load all required libraries from the folder. By this, all distribution scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provided by Java Web Start is not clear to me yet.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib). libxine-java should use the ''Self Inspection'' to check the classpath and load all required libraries from the folder. By this, all distribution scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provided by Java Web Start is not clear to me yet.
Changed lines 19-21 from:
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so the libraries have to be shipped anyway.
Finally, I've taken a lookfor the way Java apps are provided by different projects. It looks like there is a common agreement on which is the best way to deploy a Java application for a particular platform:
Finally, I've taken a look
to:
* On Windows, there are AFAIK no package managers for open-source software, especially none that provides xine-lib, so the libraries have to be shipped anyway.
Finally, I've taken a look at the way Java apps are provided by different projects. It looks like there is a common agreement over the best way to deploy a Java application for a particular platform:
Finally, I've taken a look at the way Java apps are provided by different projects. It looks like there is a common agreement over the best way to deploy a Java application for a particular platform:
Changed lines 23-29 from:
* On Linux, applications (e.g. Eclipse) are shipped as an archived application folder that contains a startup script. Inside this folder, all required libs are stored similar to the Mac OS X application bundle.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'')again can either contain the absolute path to the folder (as it was created by the installer) or can dynamically determine its location and invoke the Java VM accordingly.
In addition to these, Java Web Start allows to store all JARs and other resources including native libraries on a web server, and just specify thecorresponging URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib..). libxine-java should check the classpath to find this folder and load all required libraries from there. By this, all scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provide by Java Web Start is not clear to me yet.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'')
In addition to these, Java Web Start allows to store all JARs and other resources including native libraries on a web server, and just specify the
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib
to:
* On Linux, an application (e.g. Eclipse) is shipped as an archived application folder that contains a startup script. Inside this folder, all required libs are stored similar to the Mac OS X application bundle.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') can either contain the absolute path to the folder (as it was created by the installer) or can dynamically determine its location and invoke the Java VM accordingly.
In addition to these, Java Web Start allows to store all JARs and other resources, including native libraries, on a web server, and just specify the corresponding URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib). libxine-java should check the classpath to find this folder and load all required libraries from there. By this, all scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provide by Java Web Start is not clear to me yet.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') can either contain the absolute path to the folder (as it was created by the installer) or can dynamically determine its location and invoke the Java VM accordingly.
In addition to these, Java Web Start allows to store all JARs and other resources, including native libraries, on a web server, and just specify the corresponding URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib). libxine-java should check the classpath to find this folder and load all required libraries from there. By this, all scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provide by Java Web Start is not clear to me yet.
Changed lines 12-15 from:
* If the final application is started by startup script, the script can determine its location and start the Java VM with an appropriate java.library.path.
* A variation of the last approach is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
* A variation of the last approach is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
to:
* ''Startup Script'': If the final application is started by startup script, the script can determine its location and start the Java VM with an appropriate java.library.path.
* ''Self Inspection'': A variation of the last approach is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
* ''Self Inspection'': A variation of the last approach is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
Changed line 17 from:
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed and the provision of an error message, if they are missing, should be all that is needed.
to:
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So, a simple test if the libs are installed, and the provision of an error message if they are missing, should be all that is needed.
Changed lines 1-2 from:
!! Binary Distribution of Java Apps and Libs which Include Native Libraries.. Or How to Package libxine-java?
to:
!! Binary Distribution of Java Apps and Libs which Include Native Libraries... Or How to Package libxine-java?
Changed lines 1-2 from:
!! Binary Distribution of Java Apps and Libs which Include Native Libraries -- How to package libxine-java?
to:
!! Binary Distribution of Java Apps and Libs which Include Native Libraries.. Or How to Package libxine-java?
Changed lines 3-6 from:
Although any kind of file and especially native libraries can be stored in JARs, native libraries cannot be loaded from JARs by the system dynamic loader.
In Java, there are3 ways in which native libs can be found and loaded:
* They are placed in the systemlibs folder (/usr/lib on Mas OS X and Linux, C:\\WINDOWS\\system32 on Win32).
In Java, there are
* They are placed in the system
to:
Although any kind of file, and especially native libraries, can be stored in JARs, native libraries cannot be loaded from there by the system dynamic loader.
In Java, there are three ways in which native libs can be found and loaded:
* They are placed in the system library folder (/usr/lib on Mas OS X and Linux, C:\\WINDOWS\\system32 on Win32).
In Java, there are three ways in which native libs can be found and loaded:
* They are placed in the system library folder (/usr/lib on Mas OS X and Linux, C:\\WINDOWS\\system32 on Win32).
Changed lines 10-11 from:
Similar to these options, various project use different strategies to load their libs:
* ''Extract to /tmp and Load'':Eclipse SWT provides its native libs inside the platform-specific JAR. However, it first tries to load its libs from the system folder. If the lib is not found, SWT extract its libraries into the Java temp folder (/tmp on Mac OS X and Linux) and load it from there. Also this allows to only ship a single JAR, it is not optimal for xine-lib as it contains more than hundred plug-ins which all have to be extracted on the first start after a reboot.
* ''Extract to /tmp and Load'':
to:
Similar to these options, various projects use different strategies to load their libraries:
* ''Extract to /tmp and Load'': The SWT project provides its native libraries inside a platform-specific JAR. However, it first tries to load a native library from the system folder. If the library is not found, SWT extract its libraries into the Java temp folder (/tmp on Mac OS X and Linux) and loads them from there. Although this allows to ship only a single JAR, it is not optimal for xine-lib. xine-lib contains more than one hundred plug-ins which all would have to be extracted on the first start after a reboot.
* ''Extract to /tmp and Load'': The SWT project provides its native libraries inside a platform-specific JAR. However, it first tries to load a native library from the system folder. If the library is not found, SWT extract its libraries into the Java temp folder (/tmp on Mac OS X and Linux) and loads them from there. Although this allows to ship only a single JAR, it is not optimal for xine-lib. xine-lib contains more than one hundred plug-ins which all would have to be extracted on the first start after a reboot.
Changed lines 13-25 from:
* A variation of the second one is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there it can access the requires libs using their absolute paths.
In addition to the nativelibs provided by libxine-java, to actually use libxine-java, the xine-lib and related libs such as libdvdread and libdvdcss are required. If these libs should be included in a libxine-java package depends on the depoyment platform:
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed andan error message, if they are missing, should be all that is needed.
* On Mac OS X, xine-lib can be provided by[[http://www.finkproject.org | Fink ]] or [[http://www.macports | MacPorts ]]. However, requiring the end user to install xine with one of the two is cumbersome. It would be better to just ship xine-lib binaries.
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so thelibs have to be shipped anyway.
Finally, I've taken a look for the way Java apps are provided bydiffernt projects. It looks like there is a common agreement on which is the best way to deploy a Java app on a particular platform:
* On Mac OS X,an GUI-application consists on a folder which contains everything required. All JARs and native libs can be placed inside the folder. The folder is finally provided inside a ZIP archive or a DMG disk image.
* On Linux, applications (e.g. Eclipse) are shipped as an archived folder which contains a startup script. Inside this folder, all required libs are stored, too.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') again can either contain the absolute path to the folder or can dynamically determine its location and invoke the Java VM accordingly.
In addition to the native
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed and
* On Mac OS X, xine-lib can be provided by
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so the
Finally, I've taken a look for the way Java apps are provided by
* On Mac OS X,
* On Linux, applications (e
* On Windows, the preferred way
to:
* A variation of the last approach is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there, it can access the requires libraries using their absolute paths.
In addition to the native libraries provided by libxine-java, to actually use libxine-java, the xine-lib and related libs such as libdvdread and libdvdcss are required. If these libraries should be included in a future libxine-java package depends on the deployment platform:
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed and the provision of an error message, if they are missing, should be all that is needed.
* On Mac OS X, xine-lib can be provided by [[http://www.finkproject.org | Fink ]] or [[http://www.macports | MacPorts ]]. However, requiring the end user to install xine-lib with one of the two is cumbersome. It would be better to just ship the complete xine-lib binaries.
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so the libraries have to be shipped anyway.
Finally, I've taken a look for the way Java apps are provided by different projects. It looks like there is a common agreement on which is the best way to deploy a Java application for a particular platform:
* On Mac OS X, a GUI-application consists of a folder (named ApplicationName.app), which contains everything required. All JARs and native libs can be placed inside this folder. The folder can then be downloaded as a ZIP archive or a DMG disk image.
* On Linux, applications (e.g. Eclipse) are shipped as an archived application folder that contains a startup script. Inside this folder, all required libs are stored similar to the Mac OS X application bundle.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') again can either contain the absolute path to the folder (as it was created by the installer) or can dynamically determine its location and invoke the Java VM accordingly.
In addition to these, Java Web Start allows to store all JARs and other resources including native libraries on a web server, and just specify the corresponging URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib..). libxine-java should check the classpath to find this folder and load all required libraries from there. By this, all scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provide by Java Web Start is not clear to me yet.
In addition to the native libraries provided by libxine-java, to actually use libxine-java, the xine-lib and related libs such as libdvdread and libdvdcss are required. If these libraries should be included in a future libxine-java package depends on the deployment platform:
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed and the provision of an error message, if they are missing, should be all that is needed.
* On Mac OS X, xine-lib can be provided by [[http://www.finkproject.org | Fink ]] or [[http://www.macports | MacPorts ]]. However, requiring the end user to install xine-lib with one of the two is cumbersome. It would be better to just ship the complete xine-lib binaries.
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so the libraries have to be shipped anyway.
Finally, I've taken a look for the way Java apps are provided by different projects. It looks like there is a common agreement on which is the best way to deploy a Java application for a particular platform:
* On Mac OS X, a GUI-application consists of a folder (named ApplicationName.app), which contains everything required. All JARs and native libs can be placed inside this folder. The folder can then be downloaded as a ZIP archive or a DMG disk image.
* On Linux, applications (e.g. Eclipse) are shipped as an archived application folder that contains a startup script. Inside this folder, all required libs are stored similar to the Mac OS X application bundle.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') again can either contain the absolute path to the folder (as it was created by the installer) or can dynamically determine its location and invoke the Java VM accordingly.
In addition to these, Java Web Start allows to store all JARs and other resources including native libraries on a web server, and just specify the corresponging URLs in a JNLP XML file.
For libxine-java, I'll try to provide a single folder which contains a JAR and all required libs (including xine-lib..). libxine-java should check the classpath to find this folder and load all required libraries from there. By this, all scenarios are fine. If xine-lib (with the one hundred plug-ins) can be provide by Java Web Start is not clear to me yet.
Changed lines 22-37 from:
* On Mac OS X, an GUI-application consists on a folder which contains everything required.
a ZIP-file or a DMG disk image contain a Mac Application fold
required libs: xine-lib, libdvdread, libdvdcss
ship or rely on native platform to provide them. decision depends on platform:
* linux: package manager should provide current version
* mac: fink or macport, but not everyone is using them
* windows: no way. xine is not installed
http://wwwmacports.org/
a ZIP-file or a DMG disk image contain a Mac Application fold
required libs: xine-lib, libdvdread, libdvdcss
ship or rely on native platform to provide them. decision depends on platform:
* linux: package manager should provide current version
* mac: fink or macport, but not everyone is using them
* windows: no way. xine is not installed
http://www
to:
* On Mac OS X, an GUI-application consists on a folder which contains everything required. All JARs and native libs can be placed inside the folder. The folder is finally provided inside a ZIP archive or a DMG disk image.
* On Linux, applications (e.g. Eclipse) are shipped as an archived folder which contains a startup script. Inside this folder, all required libs are stored, too.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') again can either contain the absolute path to the folder or can dynamically determine its location and invoke the Java VM accordingly.
* On Linux, applications (e.g. Eclipse) are shipped as an archived folder which contains a startup script. Inside this folder, all required libs are stored, too.
* On Windows, the preferred way to distribute an application is to provide a GUI-installer. Such an installer can create a folder in C:\\Program\ Files\NewAppName and put all JARs and libs in there. A startup script (''batch script'') again can either contain the absolute path to the folder or can dynamically determine its location and invoke the Java VM accordingly.
Changed lines 16-17 from:
to:
In addition to the native libs provided by libxine-java, to actually use libxine-java, the xine-lib and related libs such as libdvdread and libdvdcss are required. If these libs should be included in a libxine-java package depends on the depoyment platform:
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed and an error message, if they are missing, should be all that is needed.
* On Mac OS X, xine-lib can be provided by [[http://www.finkproject.org | Fink ]] or [[http://www.macports | MacPorts ]]. However, requiring the end user to install xine with one of the two is cumbersome. It would be better to just ship xine-lib binaries.
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so the libs have to be shipped anyway.
Finally, I've taken a look for the way Java apps are provided by differnt projects. It looks like there is a common agreement on which is the best way to deploy a Java app on a particular platform:
* On Mac OS X, an GUI-application consists on a folder which contains everything required.
a ZIP-file or a DMG disk image contain a Mac Application fold
* On Linux, it is safe to assume that xine-lib and related libs can be provided by a package manager (e.g. for Debian/Ubuntu/OpenSuse..). So a simple test if the libs are installed and an error message, if they are missing, should be all that is needed.
* On Mac OS X, xine-lib can be provided by [[http://www.finkproject.org | Fink ]] or [[http://www.macports | MacPorts ]]. However, requiring the end user to install xine with one of the two is cumbersome. It would be better to just ship xine-lib binaries.
* On Windows, there are AFAIK no package managers, especially none that provides xine-lib, so the libs have to be shipped anyway.
Finally, I've taken a look for the way Java apps are provided by differnt projects. It looks like there is a common agreement on which is the best way to deploy a Java app on a particular platform:
* On Mac OS X, an GUI-application consists on a folder which contains everything required.
a ZIP-file or a DMG disk image contain a Mac Application fold
Changed lines 10-16 from:
different approaches;
* extract and load
* startup script
* check classpath and
to:
Similar to these options, various project use different strategies to load their libs:
* ''Extract to /tmp and Load'': Eclipse SWT provides its native libs inside the platform-specific JAR. However, it first tries to load its libs from the system folder. If the lib is not found, SWT extract its libraries into the Java temp folder (/tmp on Mac OS X and Linux) and load it from there. Also this allows to only ship a single JAR, it is not optimal for xine-lib as it contains more than hundred plug-ins which all have to be extracted on the first start after a reboot.
* If the final application is started by startup script, the script can determine its location and start the Java VM with an appropriate java.library.path.
* A variation of the second one is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there it can access the requires libs using their absolute paths.
* ''Extract to /tmp and Load'': Eclipse SWT provides its native libs inside the platform-specific JAR. However, it first tries to load its libs from the system folder. If the lib is not found, SWT extract its libraries into the Java temp folder (/tmp on Mac OS X and Linux) and load it from there. Also this allows to only ship a single JAR, it is not optimal for xine-lib as it contains more than hundred plug-ins which all have to be extracted on the first start after a reboot.
* If the final application is started by startup script, the script can determine its location and start the Java VM with an appropriate java.library.path.
* A variation of the second one is that a Java lib can inspect the classpath (java.class.path) for the path to its JAR. From there it can access the requires libs using their absolute paths.
Changed lines 1-11 from:
!! How to package libxine-java?
''This page documents my ideas on how libxine-java is distributed''
native libs can be stored in JARs, but not loaded from there by the system dynamic loader.
explain hownative libs are loaded. 3 options:
* system libs folder
* -Djava.library.path
* absolute path
''This page documents my ideas on how libxine-java is distributed''
native libs can be stored in JARs, but not loaded from there by the system dynamic loader.
explain how
* system libs folder
* -Djava
* absolute
to:
!! Binary Distribution of Java Apps and Libs which Include Native Libraries -- How to package libxine-java?
Although any kind of file and especially native libraries can be stored in JARs, native libraries cannot be loaded from JARs by the system dynamic loader.
In Java, there are 3 ways in which native libs can be found and loaded:
* They are placed in the system libs folder (/usr/lib on Mas OS X and Linux, C:\\WINDOWS\\system32 on Win32).
* The location of native libs are specified using the java.library.path property when the Java VM is invoked.
* A native library can be loaded directly from an absolute path.
Although any kind of file and especially native libraries can be stored in JARs, native libraries cannot be loaded from JARs by the system dynamic loader.
In Java, there are 3 ways in which native libs can be found and loaded:
* They are placed in the system libs folder (/usr/lib on Mas OS X and Linux, C:\\WINDOWS\\system32 on Win32).
* The location of native libs are specified using the java.library.path property when the Java VM is invoked.
* A native library can be loaded directly from an absolute path.
Changed lines 5-10 from:
native
how native libs are loaded. 3 options
to:
native libs can be stored in JARs, but not loaded from there by the system dynamic loader.
explain how native libs are loaded. 3 options:
* system libs folder
* -Djava.library.path
* absolute path
explain how native libs are loaded. 3 options:
* system libs folder
* -Djava.library.path
* absolute path
Changed lines 17-24 from:
required libs: xine-lib
ship or rely on native platform to provide them
linux: package manager should provide current version
mac: fink or macport, but not everyone is using them
windows: no way
mac
windows: no
to:
required libs: xine-lib, libdvdread, libdvdcss
ship or rely on native platform to provide them. decision depends on platform:
* linux: package manager should provide current version
* mac: fink or macport, but not everyone is using them
* windows: no way. xine is not installed.
ship or rely on native platform to provide them. decision depends on platform:
* linux: package manager should provide current version
* mac: fink or macport, but not everyone is using them
* windows: no way. xine is not installed.
Added lines 1-24:
!! How to package libxine-java?
''This page documents my ideas on how libxine-java is distributed''
document
native libs can be stored in JARs, but not loaded from the system dynamic loader
how native libs are loaded. 3 options. system libs folder, -Djava.library.path, absolute path
different approaches;
* extract and load
* startup script
* check classpath and load absolute
required libs: xine-lib
ship or rely on native platform to provide them
linux: package manager should provide current version
mac: fink or macport, but not everyone is using them
windows: no way
http://www.macports.org/
''This page documents my ideas on how libxine-java is distributed''
document
native libs can be stored in JARs, but not loaded from the system dynamic loader
how native libs are loaded. 3 options. system libs folder, -Djava.library.path, absolute path
different approaches;
* extract and load
* startup script
* check classpath and load absolute
required libs: xine-lib
ship or rely on native platform to provide them
linux: package manager should provide current version
mac: fink or macport, but not everyone is using them
windows: no way
http://www.macports.org/