Hi there,
On 01/02/2007, at 2:21 AM, Kieran Kelleher wrote:
> What about just embedding all frameworks in your new Eclipse
> projects, thus eliminating dependency on the deployment environment
> (probably with exception of /System/Library/Frameworks stuff?
That's called a work-a-round ;-) And of course I'm quite capable of
doing it... but the problem is that upon deployment of new apps
they'll have things in the classpath (from /Library/WebObjects/
Extensions) not anticipated won't they...
I'm simply putting forward a vote (for want of a better word) for a
'tick this box to enable/disable' including items in /Library/
WebObjects/Extensions in the classpath during development as I'd like
to simulate the real deployment environment that I'm working with
(not to mention other people too).
Is that too much to ask? :-)
Here's my view... the tool shouldn't dictate to me what features of
the runtime I can and cannot have access to. Sure provide a sensible
default - but don't hide from me options that are really available
and which sometimes can be needed.
> On Jan 30, 2007, at 5:39 PM, Lachlan Deck wrote:
>
>> On 30/01/2007, at 11:43 PM, Kieran Kelleher wrote:
>>
>>> Does /Library/Java/Extensions give you the behaviour you want
>>> instead of /Library/WebObjects/Extensions ?
>>
>> No, not really. This thread/request is about enabling access to a
>> reality of the WebObjects runtime environment - regardless of
>> whether there's better strategies. It's of specific importance for
>> deployment environments where the /Library/WebObjects/Extensions
>> is already in use.
>>
>> To pull everything out of there would mean having to upgrade every
>> single application. Not fun.
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Wed Jan 31 2007 - 18:51:32 EST