These presently don't work if you are using reasonably current versions
of JDK and SWT. Made this optional if you just run ant, but left it
enabled by default since it ought to be fixed. Linux build scripts may
just provide an ACBuild.properties that turns it off so that e.g., the
ant build helper doesn't need any custom configuration.
According to https://stackoverflow.com/questions/5103384, ant 1.8
introduced a "misfeature" of providing the ant runtime by default in the
java classpath. This causes some problems with reproducible builds,
which is why later versions have a warning not to do it.
The solution is to make the inclusion of ant.jar in the classpath
explicit. That's been done now.
This isn't significantly shorter than the first pass, but it's easier to
read and maintain. To add a new platform to this (if anyone wants to do
that), just add sane default paths to ACBuild-default.properties, add a
conditional to detect your platform, and add an init-platform target
that does the configuration.
There's a bit cleaner solution in ant-contrib using the if task, but
that means adding to the dependencies and therefore the complexity of
building this thing. I'm disinclined to do that.
Previously AC built onm Windows or not Windows (assumed to be Mac).
It appears there was a means to build using gcj, but this is not
necessary, does not work anymore as configured, and isn't what we want
anyway.
Here's a first pass at improving that situation. It's a bit ugly at
present because it requires a lot of markup to do something that should
be simple. Still, I'd rather do this in steps.
Okay, the Mac build at this point finishes and has all the pieces
correctly where they ought to be. However there is something wrong with
swt. I can't get any version of it I've tried to work. I can get the
app to start but the GUI doesn't work once you load a file. And the
only way it starts like that from the app bundle is if the line adding
SWT to the classpath of the bundle is removed.
However it's not SWT's jar itself since if you run the jarfile by hand
and add the same SWT to the classpath, it doesn't immediately crash. It
runs with the same GUI problem as if yu didn't specify it in the
classpath at all.
Something fishy is going on here. But it builds, so perhaps others can
assist in figuring out the nature of the problem. That's enough for me
to move on to the Linux build.
Here's a (very rough) implementation of a macBundle task using the
universalJavaApplicationStub and jarbundler. Jarbundler's support files
(ant build system and docs) are suffering bitrot, and I don't grok maven
yet, so I'm really flying blind with it, so basically I'm committing it
in a "baseline" working (if ugly) state.
So ... _why_ use this?
The old way of bundling Java apps doesn't work anymore. It tells you to
get Apple's (compromised/unsafe) Java 6 and when you do it throws an
error because your code compiled on Oracle JDK 8/9 won't run on it
anymore.
You're supposed to duplicate the JRE in each Java program you bundle as
you would a private/custom framework. Yes, really. This solves the
dependency issues at the cost of heavy resource waste. Except every new
JDK generation changes HOW you do that, and the current method is
totally proprietary to Oracle's JDK. For cross-platform development, it
is NOT fun.
So there's uJAS, which is literally a complex shell script to magically
do the equivalent of typing java -jar <your program> from the command
line—which does work BTW if all your dependencies are properly in your
default classpath, etc. There used to be a couple of application
bundler options, but the one that still works (only with uJAS if you
have the most recent JDKs), is jarbundler.
TODO: Clean this up, restore original functionality (zipball), include
the commandline jar, etc.
committing it in this state is that jarbundler's repo is a bit of a
mess. The current version (and the version we need) is 3.3.0, the
"latest" from 2015. The docs, examples, and the ant build system are
all literally bitrotting from version 2.x, and do not work without some
fixes.
So in other words, I'm committing this in a state that I got to work so
that if I screw it up, since I'm flying blind, I'll have a messy but
working fallback.
Okay, so _why_ use any of this at all?
If you create an ACBuild.properties file and run ant, you can get
AppleCommander.app to build, but it won't run. It tells you that you
need to download Apple's legacy Java 6 which is neither safe nor
supported anymore. If you install this, it will still give you an
error because the generated code can't run under Java 6.
What you're supposed to do now is bundle your JRE with every Java
application bundle, which means multiple copies of libs on disk and in
memory. Yes, really. Except Oracle keeps changing how you do this with
each new JDK generation, and the current way is pretty much totally
proprietary so that you're locked in to Oracle's JDK and couldn't use
OpenJDK or something if that were an option.
That's what universalJavaApplicationStub resolves—it builds an app
bundle that uses whatever JDK/JRE you have installed from 6 onwards.
And it in turn needs jarbundler or something like it. Except all of the
"something like it" solutions are dead or deprecated save the latest
release of jarbundler which was modified to support uJAS and then
promptly left more or less untouched since. But it "works".
When one creates a subdirectory on a ProDOS volume, the master entry in the subdirectory's key block needs to point back to its parent directory block and entry number. However, the code for setting those things is missing.
Side effect: opened up the previously private 'Name' class in ui; this simplifies directory handling elsewhere, as it automatically creates a directory structure to a pathed file.
