Handle platform specific jars and native libraries

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.2.x, 0.3
  • Fix Version/s: 0.3
  • Component/s: cli
  • Labels:
    None

Description

There are times where platform-specific jars and libraries must be taken into account to make an application work, most notable anything that is related to 3d (JOGL for example). It would be great if Griffon were to handle packaging of native jars and libraries.

Proposal:
1. allow the following layout on an application or plugin

-basedir
+--lib
|+--windows
| +-- native
|+-- linux
| +-- native
|+-- macosx
  +-- native

2. lib/windows contains jar files, lib/windows/native contains .dll files
3. initially supported platforms: windows, linux, macosx (disregarding a distinction between 32 and 64 version)
4. native jars and libraries that match the current platform will be copied when run-app is invoked with 'development' environment
5. run-applet and run-webstart should rely on jnlp extensions to load native jars and libs
6. all native jars and libraries will be copied when packaging with an environment != 'development'
7. launch scripts will honor native jars and libs

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
James Williams added a comment -

I like the flow of this. Minor point though, I think the mac target should be osx or mac since macosx is listing both the OS and version differing from how the windows and linux targets are titled.

Are you thinking to do another level for 64-bit? ie /XXX/native/64/XXX.dynlib

How will the installer plugin piggyback on this to make more fine-grained installers?

Show
James Williams added a comment - I like the flow of this. Minor point though, I think the mac target should be osx or mac since macosx is listing both the OS and version differing from how the windows and linux targets are titled. Are you thinking to do another level for 64-bit? ie /XXX/native/64/XXX.dynlib How will the installer plugin piggyback on this to make more fine-grained installers?
Hide
Permalink
Andres Almiray added a comment -

I thought of choosing osx instead of macosx but given that GriffonPlatformUtils already uses macosx decided to keep the latter.
I believe adding another level is not a good idea. I guess we can pick windows64, linux64 and so forth when we're ready to support 64 versions, however that is open to discussion of course.

A prototype is almost ready, including a jogl plugin.

Show
Andres Almiray added a comment - I thought of choosing osx instead of macosx but given that GriffonPlatformUtils already uses macosx decided to keep the latter. I believe adding another level is not a good idea. I guess we can pick windows64, linux64 and so forth when we're ready to support 64 versions, however that is open to discussion of course. A prototype is almost ready, including a jogl plugin.
Hide
Permalink
James Williams added a comment -

Re: naming, touché.

On the 64-bit front, I was more concerned about OSX SL because IIRC that is the line where 64-bit v 32-bit Java is drawn. Linux64 follows that in priority and Win64 is probably of lowest priority and prevalence.

I guess the question I'm asking is are we planing to target pre-Snow Leopard in the prototype or Snow Leopard and higher?

re:prototype, cool, I look forward to checking it out.

Show
James Williams added a comment - Re: naming, touché. On the 64-bit front, I was more concerned about OSX SL because IIRC that is the line where 64-bit v 32-bit Java is drawn. Linux64 follows that in priority and Win64 is probably of lowest priority and prevalence. I guess the question I'm asking is are we planing to target pre-Snow Leopard in the prototype or Snow Leopard and higher? re:prototype, cool, I look forward to checking it out.
Hide
Permalink
Alexander Scott added a comment -

The release notes seemed to indicate that this feature was completed for release 3.0.

However I am having an issue with this. When I add a /lib/windows/native folder with some dlls, when I try and run the application I get;
Loading with installed plug-ins: [i18n] ...
[mkdir] Created dir: C:\projects\griffon\deviceclient\staging\windows
[mkdir] Created dir: C:\projects\griffon\deviceclient\staging\windows\native
[copy] Copying 1 file to C:\projects\griffon\deviceclient\staging\windows\native
[copy] Copying 1 file to C:\projects\griffon\deviceclient\staging\windows\native
[copy] Copying 1 file to C:\projects\griffon\deviceclient\staging\windows\native
java.lang.NoClassDefFoundError: Files\Java\jdk1/6/0_18\bin;/;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program
Caused by: java.lang.ClassNotFoundException: Files\Java\jdk1.6.0_18\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: Files\Java\jdk1.6.0_18\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program. Program will exit.
Exception in thread "main"
Process finished with exit code 0

It looks some a classpath issue to me? I'll raise a defect if required, but I wanted to make sure this feature is implemented first - and that I am using it correctly.

Show
Alexander Scott added a comment - The release notes seemed to indicate that this feature was completed for release 3.0. However I am having an issue with this. When I add a /lib/windows/native folder with some dlls, when I try and run the application I get; Loading with installed plug-ins: [i18n] ... [mkdir] Created dir: C:\projects\griffon\deviceclient\staging\windows [mkdir] Created dir: C:\projects\griffon\deviceclient\staging\windows\native [copy] Copying 1 file to C:\projects\griffon\deviceclient\staging\windows\native [copy] Copying 1 file to C:\projects\griffon\deviceclient\staging\windows\native [copy] Copying 1 file to C:\projects\griffon\deviceclient\staging\windows\native java.lang.NoClassDefFoundError: Files\Java\jdk1/6/0_18\bin;/;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Caused by: java.lang.ClassNotFoundException: Files\Java\jdk1.6.0_18\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: Files\Java\jdk1.6.0_18\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program. Program will exit. Exception in thread "main" Process finished with exit code 0 It looks some a classpath issue to me? I'll raise a defect if required, but I wanted to make sure this feature is implemented first - and that I am using it correctly.
Hide
Permalink
Andres Almiray added a comment -

Alexander, I believe you're experiencing the problem described by http://jira.codehaus.org/browse/GRIFFON-156 mainly, spaces in the application's path can cause some trouble. I've confirmed this happens on Mac OSX, you just confirmed it happens on Windows too.

Show
Andres Almiray added a comment - Alexander, I believe you're experiencing the problem described by http://jira.codehaus.org/browse/GRIFFON-156 mainly, spaces in the application's path can cause some trouble. I've confirmed this happens on Mac OSX, you just confirmed it happens on Windows too.
Hide
Permalink
Andres Almiray added a comment -

Closing this issue as http://jira.codehaus.org/browse/GRIFFON-156 keeps track of the 'spaces in path' problem.

Show
Andres Almiray added a comment - Closing this issue as http://jira.codehaus.org/browse/GRIFFON-156 keeps track of the 'spaces in path' problem.
Hide
Permalink
Alexander Scott added a comment -

Andres,

Actually this is caused because I had the native DLLs in /lib/windows/native/, but I did not have the JARs in /lib/windows/ (I had left them in /lib/).
I just copied the JARs into /lib/windows/ and it seems to be working correctly.

Thanks for the rapid response.

Show
Alexander Scott added a comment - Andres, Actually this is caused because I had the native DLLs in /lib/windows/native/, but I did not have the JARs in /lib/windows/ (I had left them in /lib/). I just copied the JARs into /lib/windows/ and it seems to be working correctly. Thanks for the rapid response.

People

  • Assignee:
    Andres Almiray
    Reporter:
    Andres Almiray
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: