Re: Basic Question
Re: Basic Question
- Subject: Re: Basic Question
- From: "Jerry W. Walker" <email@hidden>
- Date: Wed, 22 Mar 2006 18:17:01 -0500
On Mar 22, 2006, at 4:42 PM, Jeffrey Pearson wrote:
So am I also understanding correctly that if you are 'adding an
existing' asset, it doesnt actually copy the file to the target but
expects it to already exist there?
No.
On Mar 22, 2006, at 4:45 AM, Jean Pierre Malrieu wrote:
OK. I SO didn't even understand ANY of that. Can you translate to a
lower beginner level? I am coming from using IntelliJ and the JSP/
Servlet world. I simply dropped the folder of images into my
resources folder which contained all of my jsp files and it was
deployed with the rest of the jsp files.
Trying to duplicate this, I first copied my images folder into the
project root folder in the finder.
In XCode, in the Groups and Files pane, I right click on the 'Web
Components' folder and selected 'Add Existing Files', and selected
the folder that I just copied over. I now see my images folder and I
can drill down and see my individual images in the folder under the
Web Components folder in the Groups and Files pane.
I'm not understanding.......
So, let's try again. This time, with feeling. :-)
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:
This email sent to email@hidden