This is jEdit as Mac OS X application bundle, based on current Java 7
from Oracle, instead of the dead an buried Java 6 from Apple. Current
7u40 even supports Retina displays.
The main application launcher is http://java.net/projects/appbundler
from Oracle, see its appbundler-1.0.jar (it contains an ant task to do
the bundling on some running Mac OS X system, but the directory layout
and Info.plist file can be created by other means as well, on any
platform.)
The resulting directory layout of jEdit.app is as follows, based on
existing jEdit-5.1.0 for Mac OS X:
Contents/MacOS/JavaAppLauncher # main launcher from appbundler-1.0.jar
Contents/Info.plist # handwritten version based on ant output
Contents/Java/ # jedit.jar and all the rest (formerly Resources/Java/)
Contents/PlugIns/jdk/ # full jdk, or trimmed version produced by appbundler ant
task
Contents/Resources/icon.icns # regular jEdit icon as before
Contents/Resources/file.icns # presently unused, no file types yet
The appbundler ant task takes a locally installed jdk as a starting
point to bundle a subset of it into the application. This is now the
official policy of Oracle and Apple. Note that plain jre does not
work here at the moment -- reasons unknown. For demonstration
purposes I've made Contents/PlugIns/jdk a symlink to some jdk found
locally on the system, but an official version should include a
self-contained copy of it.
Moreover, note that appbundler-1.0 does not handle file types yet.
There is a fork of the Oracle project here
https://bitbucket.org/infinitekind/appbundler that does that, apart
from other improvements, but I did not manage to make this work yet.
Further required changes on the jEdit side:
* Debug.ALTERNATIVE_DISPATCHER = false (always). Maybe even remove
that alternative key event dispatcher altogether. It is not
required in Java 6, and breaks Java 7.
* Brushing up the MacOSX plugin, maybe dismantling some old
workarounds. In fact, it would be preferable to get Mac OS X
application support directly into jedit.jar -- this works by
dynamic method invocation via "reflection", so jEdit will be
compilable and runnable on all platforms.
| Submitted | makarius - 2013-09-14 - 15:25:48z | Assigned | nobody |
|---|---|---|---|
| Priority | 5 | Category | None |
| Status | Open | Group | None |
| Resolution | None | Visibility | No |
| 2013-09-20 - 16:01:00z ezust |
I noticed JarBundler has released a v 2.2.0 now. I will see if we can make jEdit work
with that. |
|---|---|
| 2013-09-20 - 17:36:46z ezust |
Still having same troubles (requiring install of java6), even with jarbundler 2.2. A new way of packaging the dmg is probably a good idea. |
| 2013-09-23 - 15:32:37z makarius |
According to http://informagen.com/JarBundler/ its current version 2.2.0 is still
for Java 6, not Java 7. They point to the AppBundler by Oracle, which I was also
using here: https://java.net/projects/appbundler/ Even better might be https://bitbucket.org/infinitekind/appbundler but I did not manage yet, to make it all work as AppBundler. |
| 2013-09-23 - 22:54:16z ezust |
So this "patch" which is not actually a patch can't really be closed until we replace
jarbundler with some sort of appbundler in jEdit's source code tree and incorporate
some of the files in this bundle you have, for the dist-mac target. Vampire, can I assign this one to you? |
| 2013-10-26 - 16:19:20z ezust |
I tested your bundle, after symlinking "jdk" to a jdk 1.7.0_40 directory, and it worked
great. But why does it need to be a symlink to the JDK and not the JRE? And is there another location to symlink to that will always be the latest? Because the "Latest" in the other macos folder always thinks it is JDK 1.6. Anyway, when I installed jdk7u45, this bundle kept using the 7u40 and I had to manually redo the symlink. So even if the build file built the bundler correctly and installed it correctly, and was able to find the current jdk, I think it would keep breaking after each update of java. |
| 2013-11-05 - 11:37:59z makarius |
These questions of JDK vs. JRE and use of "the latest Java version" that happens to
be on the machine, touch general policies of Oracle and the relatively new appbundler
approach. Oracle seems to prefer application providers to include an appropriate
version of JDK, as produced by their ant task that is included in the appbundler.
The task takes an existing JDK installation on the machine (presumably "the latest")
and prunes it slightly to make a bundled version for the app. I did not really do it like that, since I don't understand ant. I merely looked closely at the result of the ant task for a minimal example app and derived my handwritten Info.plist from it. In Isabelle/jEdit the JDK bundling is done differently --- this is where the symlinks to jdk where coming from, to imitate the directory layout where Oracle puts an actual copy of (pruned) JDK. IIRC, the guys from https://bitbucket.org/infinitekind/appbundler have occasionally wondered about the "slim JDK" approach instead of plain JRE. Maybe we can ask them for further advice -- they maintain a fork of the original appbundler 1.0 from Oracle, one that looks a bit more advanced. The following blog could also help to figure out the best way to deliver jEdit on Mac OS X, according to the present state of affairs: http://intransitione.com/blog/take-java-to-app-store/ |
| 2013-09-14 - 15:25:49z makarius |
jEdit-java7.app.tar.gz |
|---|