Re: Frameworks and versioning
Re: Frameworks and versioning
- Subject: Re: Frameworks and versioning
- From: Chuck Hill <email@hidden>
- Date: Thu, 5 Jan 2006 12:58:54 -0800
Hi All,
On Jan 5, 2006, at 11:00 AM, Lachlan Deck wrote:
firstly, glad to see this turning into a useful discussion...
I am finding it quite interesting.
On 06/01/2006, at 4:23 AM, Robert Walker wrote:
I personally tend to agree with Arturo. Yes it does take more
discipline during development, but I consider that part of my job
as a developer. It's vital to ensure APIs don't break with changes
and bug fixes. If changes to API are necessary deprecate the old
method, and create a new one to support the API change. The trick
is in learning to recognize when a change affects the API.
Taking a look at /System/Library/Frameworks and /Library/
Frameworks you will see many frameworks written by Apple, and
other software developers.
... and I usually try, if subclassing/extending their behaviour, to
name my frameworks appropriately (e.g., LDJavaFoundation) so that
it's obvious what they're doing in relation to the provided
frameworks.
However, Cocoa and indeed WebObjects Frameworks can have multiple
embedded versions (e.g., "A", "B", "C", "Current" --> "C")
i.e.,
MyGreatFramework.framework/
Contents/
Versions/
A
B
C
Current --> B
...
I'll point out that this is a packaging / deployment convenience and
not "sharing API". All those different versions are different
binaries, physically different files.
but there's no obvious way to link to a specific deployed version
of a framework (at least, within Xcode) within a WebObjects
Application as there is for a Cocoa app. The thing that this would
enable is either being able to deploy/depend on certain
compatibility version and/or testing a new version of a framework
(e.g., version "C" with a test app) prior to changing the Current
symlink to point to "C" for other apps to benefit (if applicable).
AFAIK, this is not handled. It would have to be encoded into the
classpath files (MacOSClassPath.txt etc.) and then handled by
WOBootStrap when it generates the Java command line (with
classpath). I've never seen any indication that this was
implemented. I don't know if the WOBootStrap source is available, I
don't think so. There is an Open Source alternative (http://
www.objectstyle.org/woproject/articles/WOFLobotomy1/) that could be
extended to handle this, but Xcode still won't put the necessary info
in the classpath files.
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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