| Delivering stand-alone JARs for 32-bit vs. 64-bit Windows [message #696716] |
Thu, 14 July 2011 17:22 |
 Mark Ludwig
Messages: 3
Registered: July 2011 |
Junior Member |
|
|
I have a pure Java Application that depends on SWT (among other) APIs. I want to distribute it as a runnable JAR file. I use Export... Java -> Runnable JAR file to create such.
I see that SWT includes native code (not surprisingly), and understand that I have to use a 32-bit Eclipse installation to build a standalone JAR file that a 32-bit JVM can execute, and a 64-bit Eclipse installation for a 64-bit JVM.
Eclipse is enough of a resource consumer that I wouldn't want to run both instances concurrently anyway, so my first attempt is to use the same Workspace in both running instances, but it appears that I have to do more than just run the right version of Eclipse. This is because the way the SWT JAR is identified is by its specific path. This was done as a library entry in the Java Build Path (with specific fully-qualified path).
Some of my struggle might be that I'm missing something simple there, but I don't see any way to build against installed JAR files (in the plugins directory) without downloading the source for the plug-in (if I read that post correctly). Is there a symbolic way to refer a JAR in the plugins directory corresponding to the executing Eclipse? The idea is that the contents of the Workspace would "execute" differently according to the version of Eclipse that is executing.
Another alternative is that I can have two Workspace hierarchies. Then I'd want a way to share a project's source tree across Workspace locations. Can I do that? (If this were UNIX I'd just try symbolic links, but I doubt that any .lnk file would work in Eclipse on Windows. Does it, perchance?) I'd want to share almost everything in the two Workspace hierarchies, actually....
Is there any better way to do what I want? I hope it's clear enough: one project and source for two distinct execution environments.
The resulting JAR files must have different names, of course, too, according to the running version. For that, I'd want some symbolic way to incorporate "x86" versus "x64" or "x86_64" or something reasonably standard somewhere in the runnable JAR file's name.
Thanks!
|
|
|
Powered by
FUDForum. Page generated in 0.07602 seconds
] 
Search
Help
Register
Login
Home
