Re: Basic Question
Re: Basic Question
- Subject: Re: Basic Question
- From: Lachlan Deck <email@hidden>
- Date: Sat, 25 Mar 2006 09:22:17 +1100
Hi Jerry,
the below seems to be a very good overview that will be useful for
others for some time to come. Why not put it up here?
http://en.wikibooks.org/wiki/
Programming:WebObjects#The_Build_Products -> Overview
More specifically...
<http://en.wikibooks.org/w/index.php?title=Programming:WebObjects/
Web_Applications/Development/Build_Products/Overview&action=edit>
On 23/03/2006, at 10:17 AM, Jerry W. Walker wrote:
Xcode expects to take a given set of files, as listed in your
Groups & Files pane and from them build a finished product or set
of products such as an application, a framework, a library or a
command line tool.
It's worth noting here that the items represented in this pane are
of four types: files, directories, packages and groups. Files are
just that, files of various types with extensions indicating the
type, such as .java, .jpg, .gif, .html. Directories represent real
directories somewhere in your file system and are represented with
a blue folder icon. Package is a Mac OX X term for a directory of
files and subdirectories that are to be recognized as a unit both
by the Finder and by Xcode. They are often represented with an icon
that is indistinguishable from a file icon. If Xcode isn't familiar
with the kind of package represented, it displays them as blue
folders. Groups are the strange items in this categorization and
are pictured as yellow folders. THEY DON'T EXIST AT ALL in the file
system. They are purely organizing entities for your use in Xcode.
You can group files together in an Xcode Group in the Groups and
Files pane that are actually distributed all over the file system
of your computer. You use them in the Groups & Files pane simply to
group together those items of any of the four types just described
that you feel are related somehow.
Getting back to Xcode's products, for a typical, simple, non-
WebObjects project, the files would comprise Java or Objective C
source files which would be compiled to intermediate object files
and linked into a load module (for Objective C) or a .jar file (for
Java) for execution. That file, created for execution is what I'm
calling the product. An Xcode target is the set of files along with
the instructions necessary to build such a product. It will be
brought into existence by Xcode build processes.
The situation is complicated slightly in the case of WebObjects in
that good practice suggests something called a "split install".
That is, for WebObjects projects, Xcode expects to build at least
two products. One of these will be the WebObjects application which
will be served by the application server. The other will be a
package of static HTML pages, graphics files (.jpg and .gif files,
among others) and other files that can be served directly by Apache
as static resources.
The files that you add to the project must be identified as
belonging to the building of one or the other of these two
products. The third target, which carries the same name as your
project, is something called an aggregate target. It's sole purpose
is to group the other two targets into a single build operation by
setting the dependencies such that the aggregate target depends on
the other two. That way, by building the aggregate target, the
other two targets will automatically be built together. However,
you can also ask Xcode to build either of these other two targets
individually.
Although you should have added the static files to your project so
that they are included in the project directory, Xcode will build
two packages, one for the application server and one for the web
server and will either create (e.g. by compiling) or copy the
appropriate files to the appropriate package. If your project were
named "MyProject" and were built for deployment on Mac OS X, these
packages would have the following structures:
For the application server:
MyProject.woa
MyProject - a Unix shell script to which control is initially
passed and which sets up the execution environment under Unix
MyProject.CMD - a DOS command script to which control is
initially passed and which sets up the execution environment under
DOS/Windows
WOBootstrap.jar - a jar file containing a single class called
JavaArchiveFilter that implements the java.io.FilenameFilter interface
Contents - a directory containing all of the files necessary to
support the execution of the WO app
Info.plist - a property list file for the application
MacOS/
MyProject - a Unix shell script identical to that of
the same name at the top level of the project directory
MacOSClassPath.txt - text file containing the derived
Java ClassPath for the project
PkgInfo - a text file containing the four letter package
type (APPL = application) and the application's four letter file types
Resources/ - a directory containing the WOComponents and
other resources in the Resources group of the Groups & Files pane
UNIX/ - a directory similar to the MacOS directory but used
for deployment on Unix systems
Windows/ - a directory similar to the MacOS directory but
used for deployment on Windows systems
pbdevelopment.plist - an XML file with a single element
whose key is PBXProjectSourcePath and whose value is implied by the
name.
For the Web Server:
MyProject.woa
Contents - a directory containing all of the files necessary to
support the execution of the WO app
WebServerResources/
Hierarchy of files and folders containing static web
resources.
Although the packages are very different, they are identically
named, have similar structures and are merged in development. They
are typically ONLY separated like this for a split install. You
typically put the application server package in /Library/WebObjects/
Applications (or a local equivalent) and you typically put the
WebServer package in /Library/WebServer/Documents/WebObjects.
You can create these packages independently in various ways. I've
found it easier, recently (because of various examples of Xcode
intransigence) to simply build the project as I would for
development and physically separate the two for deployment. Other
people have various incantations to make a split install work
reliably and I'm sure they will chime in here.
Hope this helps.
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden