Apple-2-Tools
/
AppleCommander
mirror of https://github.com/AppleCommander/AppleCommander.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
AppleCommander/ant-build/build.xml

269 lines
9.4 KiB
XML
Raw Permalink Normal View History

Added more ant script automation.
2004-06-18 05:13:45 +00:00
<project name="AppleCommander" default="all" basedir="..">
ANT build script.
2003-03-16 05:27:04 +00:00
<description>
Add Mac application bundle; cross-platform build.
2008-05-24 03:37:01 +00:00
This script builds the distribution components.
ANT build script.
2003-03-16 05:27:04 +00:00
</description>
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<!-- Fix ant warning (explained: https://stackoverflow.com/questions/5103384) -->
<presetdef name="javac">
<javac includeantruntime="false" />
</presetdef>
ANT build script.
2003-03-16 05:27:04 +00:00
<property name="work" value="work"/>
<property name="classes" value="${work}/classes"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<property name="dist" value="${work}/dist"/>
ANT build script.
2003-03-16 05:27:04 +00:00
<property name="source" value="src"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<property name="testsrc" value="test"/>
ANT build script.
2003-03-16 05:27:04 +00:00
<property name="build" value="build"/>
<property name="doc" value="documentation"/>
<property name="web" value="web"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<property name="javadoc" value="${work}/javadoc"/>
Offer a way to change local file locations in build.xml via a local ACBuild.properties file (which doesn't get stored in the config management tool)
2008-06-06 16:52:56 +00:00
<property name="builddir" value="${basedir}/build" />
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
<property name="mac.dir" value="${basedir}/mac"/>
Offer a way to change local file locations in build.xml via a local ACBuild.properties file (which doesn't get stored in the config management tool)
2008-06-06 16:52:56 +00:00
<property file="${builddir}/ACBuild.properties"/>
<property file="${builddir}/ACBuild-default.properties"/>
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<!-- If you want to add a platform, create a conditional property for it here -->
Add unix build conditionals 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.
2017-11-03 14:50:28 +00:00
<condition property="isWin" value="true">
<os family="windows" />
</condition>
<condition property="isMac" value="true">
<and>
<os family="mac" />
<os family="unix" />
</and>
</condition>
<condition property="isUnix" value="true">
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<!-- macOS also provides unix, so we must explicitly exclude it here -->
Add unix build conditionals 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.
2017-11-03 14:50:28 +00:00
<and>
<os family="unix" />
<not>
<os family="mac" />
</not>
</and>
</condition>
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
Make jar signing optional
2008-06-07 12:51:19 +00:00
<condition property="signing-needed">
<available file="${keyconf}" property="keyconf-exists" />
</condition>
Add Mac application bundle; cross-platform build.
2008-05-24 03:37:01 +00:00
mac: Use universalJavaApplicationStub 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".
2017-10-30 13:14:13 +00:00
<taskdef name="jarbundler"
classname="com.ultramixer.jarbundler.JarBundler"
classpath="mac/jarbundler-core-3.3.0.jar" />
Add Mac application bundle; cross-platform build.
2008-05-24 03:37:01 +00:00
<target name="version" description="Get version from source.">
<property name="main.path" value="src/com/webcodepro/applecommander/ui"/>
<loadfile srcfile="${main.path}/AppleCommander.java" property="acVersion">
<filterchain>
<linecontainsregexp>
<regexp pattern='^.*String VERSION = ".*";.*$'/>
</linecontainsregexp>
<tokenfilter>
<replaceregex pattern='^.*String VERSION = "(.*)";.*$' replace='\1'/>
</tokenfilter>
<striplinebreaks/>
</filterchain>
</loadfile>
<echo>Building version ${acVersion}...</echo>
</target>
Make multiplatform easier to read 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.
2017-11-03 15:13:08 +00:00
<target name="init-win" if="isWin">
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<property name="antjar" value="${antJarPathWin}" />
Make multiplatform easier to read 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.
2017-11-03 15:13:08 +00:00
<property name="swtjar" value="${swtJarPathWin}" />
<property name="juintjar" value="${junitPathWin}" />
</target>
<target name="init-mac" if="isMac">
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<property name="antjar" value="${antJarPathMac}" />
Make multiplatform easier to read 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.
2017-11-03 15:13:08 +00:00
<property name="swtjar" value="${swtJarPathMac}" />
<property name="juintjar" value="${junitPathMac}" />
Change GUI option to noGui (still not default) The Mac build didn't much like the previous setup, so I inverted the condition and made sure the Mac bundle is disabled with noGui.
2017-11-03 16:54:10 +00:00
<condition property="noMacGui" value="true">
<isset property="noGui" />
Make build of GUI components optional (default) 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.
2017-11-03 16:28:42 +00:00
</condition>
Make multiplatform easier to read 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.
2017-11-03 15:13:08 +00:00
</target>
<target name="init-unix" if="isUnix">
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<property name="antjar" value="${antJarPathUnix}" />
Make multiplatform easier to read 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.
2017-11-03 15:13:08 +00:00
<property name="swtjar" value="${swtJarPathUnix}" />
<property name="juintjar" value="${junitPathUnix}" />
</target>
<target name="init" depends="version,init-win,init-mac,init-unix"
description="Ensure work directory is present">
ANT build script.
2003-03-16 05:27:04 +00:00
<mkdir dir="${work}"/>
<mkdir dir="${classes}"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<mkdir dir="${dist}"/>
<mkdir dir="${javadoc}"/>
(I think this was updated for Eclipse 3.0.)
2004-11-09 03:22:00 +00:00
<property name="guijar" value="${dist}/AppleCommander-${acVersion}.jar"/>
Fixed misspelling of "verion"; added "-" to ac.jar file name; added source tag for 1.5 compatibility.
2006-04-23 05:04:32 +00:00
<property name="cmdjar" value="${dist}/AppleCommander-${acVersion}-ac.jar"/>
Add Mac application bundle; cross-platform build.
2008-05-24 03:37:01 +00:00
<property name="maczip" value="${dist}/AppleCommander-${acVersion}-mac.zip"/>
(I think this was updated for Eclipse 3.0.)
2004-11-09 03:22:00 +00:00
<property name="srczip" value="${dist}/AppleCommander-${acVersion}-src.zip"/>
<property name="webzip" value="${dist}/AppleCommander-${acVersion}-web.zip"/>
ANT build script.
2003-03-16 05:27:04 +00:00
</target>
<target name="clean" depends="init" description="Wipes out work contents">
<delete dir="${classes}"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<delete dir="${dist}"/>
<delete dir="${javadoc}"/>
ANT build script.
2003-03-16 05:27:04 +00:00
</target>
Adjust dependency to always sign jars if possible.
2008-06-07 21:17:28 +00:00
<target name="all" depends="init,jars,macBundle,sourceZip,javadoc,websiteZip" description="Everything">
Add Mac application bundle; cross-platform build.
2008-05-24 03:37:01 +00:00
<!-- Nothing else to do - depends handles it all. -->
</target>
Adjust dependency to always sign jars if possible.
2008-06-07 21:17:28 +00:00
<target name="jars" depends="init,executableGuiJar,executableCmdJar,signJars" description="Build executable jars">
Make jar signing optional
2008-06-07 12:51:19 +00:00
<!-- Nothing else to do - depends handles it all. -->
</target>
<target name="signJars" depends="init" if="signing-needed" description="Signs the jars">
Add jarsigner task to build.xml; see comments.
2008-06-06 21:41:06 +00:00
<!-- In ACBuild.properties => keyconf=${user.home}/.secret alias=name -->
<!-- See man keytool, http://java.sun.com/j2se/1.5.0/docs/tooldocs/ -->
<loadfile srcfile="${keyconf}" property="password"/>
<signjar alias="${alias}" storepass="${password}">
<fileset dir="${basedir}">
<include name="${cmdjar}"/>
<include name="${guijar}"/>
</fileset>
</signjar>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
</target>
Make build of GUI components optional (default) 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.
2017-11-03 16:28:42 +00:00
Change GUI option to noGui (still not default) The Mac build didn't much like the previous setup, so I inverted the condition and made sure the Mac bundle is disabled with noGui.
2017-11-03 16:54:10 +00:00
<target name="executableGuiJar" depends="init" unless="noGui"
Make build of GUI components optional (default) 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.
2017-11-03 16:28:42 +00:00
description="Build GUI executable JAR">
Fix ant warning about includeantruntime 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.
2017-11-03 16:07:06 +00:00
<javac srcdir="${source}" destdir="${classes}" classpath="${antjar}:${swtjar}">
ANT build script.
2003-03-16 05:27:04 +00:00
<include name="**/*.java"/>
<exclude name="**/*Test.java"/>
Remove -Xlint:unchecked warnings Fixed all instances of warnings OpenJDK finds with -Xlint:unchecked. Merging this will at least result in a dependency on JDK 1.5 or later that I'm pretty sure of. But since the only JDKs that are really safe to use these days are versions 1.8 and 9, that's probably okay. No promises that this will make modern SWT work or anything, but it's probably at least a beginnig toward that as well.
2017-11-09 21:03:03 +00:00
<compilerarg value="-Xlint:unchecked"/>
ANT build script.
2003-03-16 05:27:04 +00:00
</javac>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<jar jarfile="${guijar}" manifest="build/manifest.mf">
ANT build script.
2003-03-16 05:27:04 +00:00
<fileset dir="${classes}"/>
<fileset dir="${source}">
<include name="**/*.dump"/>
<include name="**/*.properties"/>
<include name="**/*.gif"/>
</fileset>
<fileset dir=".">
<include name="LICENSE"/>
<include name="TODO"/>
<include name="VERSIONS"/>
</fileset>
</jar>
</target>
Change GUI option to noGui (still not default) The Mac build didn't much like the previous setup, so I inverted the condition and made sure the Mac bundle is disabled with noGui.
2017-11-03 16:54:10 +00:00
<target name="executableCmdJar" depends="init"
description="Build command-line only executable JAR">
<!-- SWT needs to be in classpath if executableGuiCmdJar didn't run -->
<javac srcdir="${source}" destdir="${classes}" classpath="${antjar}:${swtjar}">
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<include name="**/*.java"/>
<exclude name="**/*Test.java"/>
Remove -Xlint:unchecked warnings Fixed all instances of warnings OpenJDK finds with -Xlint:unchecked. Merging this will at least result in a dependency on JDK 1.5 or later that I'm pretty sure of. But since the only JDKs that are really safe to use these days are versions 1.8 and 9, that's probably okay. No promises that this will make modern SWT work or anything, but it's probably at least a beginnig toward that as well.
2017-11-09 21:03:03 +00:00
<compilerarg value="-Xlint:unchecked"/>
Remove java version restrictions, which are becoming quite problematic
2017-06-12 17:22:22 +00:00
<compilerarg value="-XDignore.symbol.file"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
</javac>
Use ac.mf to build executableCmdJar.
2008-05-29 12:45:41 +00:00
<jar jarfile="${cmdjar}" manifest="build/ac.mf">
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<fileset dir="${classes}">
<exclude name="com/webcodepro/applecommander/ui/swt/**"/>
<exclude name="com/webcodepro/applecommander/ui/images/**"/>
</fileset>
<fileset dir="${source}">
<include name="**/*.dump"/>
<include name="**/*.properties"/>
</fileset>
<fileset dir=".">
<include name="LICENSE"/>
<include name="TODO"/>
<include name="VERSIONS"/>
</fileset>
</jar>
</target>
Make build of GUI components optional (default) 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.
2017-11-03 16:28:42 +00:00
Change GUI option to noGui (still not default) The Mac build didn't much like the previous setup, so I inverted the condition and made sure the Mac bundle is disabled with noGui.
2017-11-03 16:54:10 +00:00
<target name="macBundle" depends="init,jars" if="isMac" unless="noMacGui"
Make build of GUI components optional (default) 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.
2017-11-03 16:28:42 +00:00
description="Build Mac application bundle.">
Remove some stuff I know I won't need anymore
2017-10-31 11:24:47 +00:00
<property name="mac.app" value="${dist}/AppleCommander.app"/>
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
mac: Use universalJavaApplicationStub 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".
2017-10-30 13:14:13 +00:00
<!--
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
NB: This seems like the only obvious way to turn ${swtjar}
into something we can install using jarbundler to both
copy and add to classpath. If you have a better way… :)
mac: Use universalJavaApplicationStub 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".
2017-10-30 13:14:13 +00:00
-->
Improve Mac build process a bit Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's no need for droppings all over the build tree. Also cleaned up building ${maczip} a bit to avoid extra file copying, to put the uncompressed .app in ${dist}, etc. Removed some cruft from .gitignore while I was at it. The conditional nature of building macBundle kind of bothers me a little since if you have the correct swt.jar (which we could provide and have in some versions of the build system), you could build self-contained packages for macOS and for Windows. A self-contained package for Linux is also possible, but doesn't make much sense as Linux software installation routinely involves installing dependencies, either manually or automatically.
2017-11-11 14:15:53 +00:00
<copy file="${swtjar}" tofile="${work}/swt/swt.jar" />
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
Improve Mac build process a bit Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's no need for droppings all over the build tree. Also cleaned up building ${maczip} a bit to avoid extra file copying, to put the uncompressed .app in ${dist}, etc. Removed some cruft from .gitignore while I was at it. The conditional nature of building macBundle kind of bothers me a little since if you have the correct swt.jar (which we could provide and have in some versions of the build system), you could build self-contained packages for macOS and for Windows. A self-contained package for Linux is also possible, but doesn't make much sense as Linux software installation routinely involves installing dependencies, either manually or automatically.
2017-11-11 14:15:53 +00:00
<jarbundler dir="${dist}"
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
name="AppleCommander" version="${acVersion}"
verbose="true" showPlist="true"
mac: Use universalJavaApplicationStub 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".
2017-10-30 13:14:13 +00:00
mainclass="com.webcodepro.applecommander.ui.AppleCommander"
bundleid="com.webcodepro.applecommander"
macBundle: some cleanup, remove .app skeleton
2017-10-30 15:12:16 +00:00
stubfile="${mac.dir}/universalJavaApplicationStub"
icon="${mac.dir}/AppleCommander.icns"
Ensure macOS bundle starts the SWT GUI In order to actually start the SWT-based GUI on macOS and have anything start, you need -XstartOnMainThread. This is a Cocoa limitation. If you have that (and we do now), you can pass the -swt argument and it runs. (More than I can say for Linux using the non-integrated SWT provided by Debian at the moment…) What doesn't work is the open dialog. No files are selectable unless you tell it to allow all files, and then .dsk files which the cmdline jar file can handle fine are somehow an unsupported format. Uh huh. That much at least should not be too hard to fix. Whether it works after that is fixed, I cannot say. What I can say is that the problem does not exist if you don't pass -swt, however the lack of a proper Swing GUI means it doesn't really matter because you can't do anything with the files once you've opened them.
2017-11-11 22:49:32 +00:00
arguments="-swt" startonmainthread="true"
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
jvmversion="1.6+" useJavaXKey="true" developmentregion="English"
copyright="Copyright 2002-2008 Rob Greene and John B. Matthews.">
<jarfilelist dir="${dist}" files="AppleCommander-${acVersion}.jar" />
Improve Mac build process a bit Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's no need for droppings all over the build tree. Also cleaned up building ${maczip} a bit to avoid extra file copying, to put the uncompressed .app in ${dist}, etc. Removed some cruft from .gitignore while I was at it. The conditional nature of building macBundle kind of bothers me a little since if you have the correct swt.jar (which we could provide and have in some versions of the build system), you could build self-contained packages for macOS and for Windows. A self-contained package for Linux is also possible, but doesn't make much sense as Linux software installation routinely involves installing dependencies, either manually or automatically.
2017-11-11 14:15:53 +00:00
<jarfilelist dir="${work}/swt" files="swt.jar" />
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
</jarbundler>
Remove some stuff I know I won't need anymore
2017-10-31 11:24:47 +00:00
Improve Mac build process a bit Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's no need for droppings all over the build tree. Also cleaned up building ${maczip} a bit to avoid extra file copying, to put the uncompressed .app in ${dist}, etc. Removed some cruft from .gitignore while I was at it. The conditional nature of building macBundle kind of bothers me a little since if you have the correct swt.jar (which we could provide and have in some versions of the build system), you could build self-contained packages for macOS and for Windows. A self-contained package for Linux is also possible, but doesn't make much sense as Linux software installation routinely involves installing dependencies, either manually or automatically.
2017-11-11 14:15:53 +00:00
<zip destfile="${maczip}">
<zipfileset dir="${dist}/AppleCommander.app" prefix="AppleCommander-${acVersion}-mac/AppleCommander.app" />
<zipfileset dir="${dist}" prefix="AppleCommander-${acVersion}-mac/jars">
<include name="AppleCommander-${acVersion}*.jar" />
Mac build ... builds and zips 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.
2017-11-01 19:45:56 +00:00
</zipfileset>
Improve Mac build process a bit Copy swt.jar to a directory in ${work} rather than ${mac.dir} as there's no need for droppings all over the build tree. Also cleaned up building ${maczip} a bit to avoid extra file copying, to put the uncompressed .app in ${dist}, etc. Removed some cruft from .gitignore while I was at it. The conditional nature of building macBundle kind of bothers me a little since if you have the correct swt.jar (which we could provide and have in some versions of the build system), you could build self-contained packages for macOS and for Windows. A self-contained package for Linux is also possible, but doesn't make much sense as Linux software installation routinely involves installing dependencies, either manually or automatically.
2017-11-11 14:15:53 +00:00
</zip>
Add Mac application bundle; cross-platform build.
2008-05-24 03:37:01 +00:00
</target>
ANT build script.
2003-03-16 05:27:04 +00:00
<target name="sourceZip" depends="init" description="Build source ZIP archive">
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<zip zipfile="${srczip}">
ANT build script.
2003-03-16 05:27:04 +00:00
<zipfileset dir=".">
<include name="ECLIPSE-CONFIG"/>
<include name="HEADER"/>
<include name="LICENSE"/>
<include name="NATIVE-COMPILE"/>
<include name="TODO"/>
<include name="VERSIONS"/>
</zipfileset>
<zipfileset dir="${source}" prefix="${source}">
<include name="**/*.java"/>
<include name="**/*.dump"/>
<include name="**/*.properties"/>
<include name="**/*.gif"/>
</zipfileset>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<zipfileset dir="${testsrc}" prefix="${testsrc}">
<include name="**/*.java"/>
<include name="**/*.dump"/>
<include name="**/*.properties"/>
<include name="**/*.gif"/>
</zipfileset>
ANT build script.
2003-03-16 05:27:04 +00:00
<zipfileset dir="${build}" prefix="${build}"/>
<zipfileset dir="${doc}" prefix="${doc}">
<include name="**/*.txt"/>
</zipfileset>
<zipfileset dir="${web}" prefix="${web}">
<include name="**/*.html"/>
<include name="**/*.gif"/>
<include name="**/*.png"/>
</zipfileset>
</zip>
</target>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<target name="javadoc" depends="init" description="Build javadoc">
(I think this was updated for Eclipse 3.0.)
2004-11-09 03:22:00 +00:00
<javadoc destdir="${javadoc}" author="true" windowtitle="AppleCommander ${acVersion} JavaDoc"
Exclude non-source files in javadoc target.
2008-12-16 09:33:58 +00:00
classpath="${swtjar};${junitjar}">
<fileset dir="${source}">
<exclude name="**/*gif"/>
<exclude name="**/*dump"/>
<exclude name="**/*properties"/>
</fileset>
<fileset dir="${testsrc}">
<exclude name="**/*properties"/>
</fileset>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
</javadoc>
</target>
<target name="websiteZip" depends="javadoc" description="Build website ZIP archive">
<zip zipfile="${webzip}">
Added websiteZip to all dependencies; changed web zip file to not include the htdocs directory.
2004-06-19 21:07:46 +00:00
<zipfileset dir="${web}">
Added more ant script automation.
2004-06-18 05:13:45 +00:00
<include name="**/*.html"/>
<include name="**/*.gif"/>
<include name="**/*.png"/>
</zipfileset>
Added websiteZip to all dependencies; changed web zip file to not include the htdocs directory.
2004-06-19 21:07:46 +00:00
<zipfileset dir="${javadoc}" prefix="javadoc"/>
Added more ant script automation.
2004-06-18 05:13:45 +00:00
</zip>
</target>
Add unix build conditionals 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.
2017-11-03 14:50:28 +00:00
</project>