WOApplication
WOApplication Task Manual
This has been transcribed by Andrew Lindesay from the old WOProject site.
Description
WOApplication is an Ant task to build WebObjects applications from a set of files. It does not enforce any particular project structure and can be used to create applications without using the ProjectBuilder or XCode.
Properties
WOApplication behavior depends on various properties in the wobuild.properties file that specify common locations of the frameworks used by the application. These properties can be initialized with the ant script woproperties.xml. Per default the woapplication task expects this file in $user.home/Library/wobuild.properties. If no file is found the woapplication task resolves the property WOBUILD_PROPERTIES from the java properties and the environment(in this order) to find the file.
Property from the wobuild.properties file | Description | Default |
---|---|---|
wo.wosystemroot | Usually this is a WebObjects installation directory, like "C:\Apple". | NEXT_ROOT environment variable, or root directory "/". |
wo.wolocalroot | Usually this is a "Local" directory under the directory specified by "wo.woroot". | ${wo.woroot}/Local |
wo.homeroot | Usually this is a user home directory. | ${user.home} |
Parameters
Attribute | Description | Required |
---|---|---|
name | Name of the application (without .woa extension). | Yes |
chmod | Optional value for the chmod command executed by the WOApplication task. The default is "gu+x". The chmod command is only executed on the first build of the application and only on "Unix" platforms. The default is "750". | No |
destDir | Destination directory where the application woa should be created. | Yes |
wsDestDir | Destination directory where WebServerResorces should be copied during split install (presense of this parameter will trigger split install). WebServerResources will be created under wsDestDir/WebObjects/AppName.woa/Contents/. | No |
principalClass | Subclass of WOApplication to use. | Application |
customInfoPListContent | String to append to the Info.plist. | No |
stdFrameworks | If set to true, a set of standard frameworks will be associated with the deployed application (default is true). "Standard" frameworks are: JavaWebObjects, JavaWOExtensions, JavaEOAccess, JavaEOControl, JavaFoundation, JavaJDBCAdaptor, JavaXML. | No |
jvm | Path to the JVM binary. Defaults to 'java' | No |
jvmOptions | String for the JVM options in the classpath. | No |
jdb | Path to the JVM binary. Defaults to 'java' | No |
jdbOptions | String for the jdb options in the classpath. | No |
webXML | Generate web.xml | No |
webXML_WOROOT | Optional parameter for the web.xml | No |
webXML_LOCALROOT | Optional parameter for the web.xml | No |
webXML_WOAINSTALLROOT | Optional parameter for the web.xml | No |
webXML_WOAppMode | Optional parameter for the web.xml | No |
webXML_WOtaglib | Optional parameter for the web.xml | No |
webXML_CustomContent | Optional parameter for the web.xml | No |
cfBundleVersion | CFBundleVersion for the Info.plist. Default is no version. | No |
cfBundleShortVersion | CFBundleShortVersionString for the Info.plist. Default is no version. | No |
cfBundleID | CFBundleIndetifier for the Info.plist. Defaults to 'com.myapp'. | No |
javaVersion | JVMVersion for the Info.plist. Used for selecting JVM compatibility. Defaults to '1.5+'. | No |
frameworksBaseURL | This denotes the directory containing the framework webserver resources bundles (MyFramework.framework, ERExtensions.framework, etc.). | No |
startupScriptName | ..... | No |
Nested Elements
classes
The nested classes element specifies a FileSet. All files included in this fileset will end up in the Contents/Resources/Java/*.jar file of the application.
resources
The nested resources element specifies a FileSet. All files included in this fileset will end up in the Contents/Resources directory of the application. For the discussion of resource localization issues follow this link.
wsresources
The nested wsresources element specifies a FileSet. All files included in this fileset will end up in the Contents/WebServerResources directory of the application. For the discussion of resource localization issues follow this link.
frameworks
The nested frameworks is a FrameworkSet structure that specifies the names of the WebObjects Frameworks that this application is dependant upon. The jar files from these frameworks will be referenced in varios platform-specific depoyment files (such as CLASSPATH.TXT), and specified in the web.xml classpath if an application is deployed as a servlet. When building a FileSet, path should match up to the "*.framework" directory (no need to match individual JAR files).
To embed frameworks set embed to true.
lib
The nested lib element specifies a FileSet. This should be a fileset of jar libraries required by your application. All files in this fileset will end up in the Resources/Java folder of the application, and will be included on the classpath for this application.
To embed jars set embed to true.
otherclasspath
This nested element is used to add an arbitrary directory or file path to the runtime classpath. For example on Mac OS X, the directory at APPROOT/Resources/SSLKeyStore/ can be added to the runtime classpath by doing something like this:
<woapplication>
[...]
<otherclasspath dir="." embed="true">
<include name="Resources/SSLKeyStore" />
</otherclasspath>
</woapplication>
Examples
Create an application "MyApp" with a set of standard frameworks:
Unknown macro: noformat. Click on this message for details.
Create an application "MyApp" with no implicit standard frameworks and a set of custom frameworks located under HOMEROOT (defined from the value of wo.homeroot property):
Unknown macro: noformat. Click on this message for details.
Create an application "MyApp" with embedded frameworks:
Unknown macro: noformat. Click on this message for details.