Anjo,
I am absolutely convinced that you need to patch the base framework,
but I want to point a couple of things:
1- There need to be a way to remove the patches for people that want
to move on and use WO 5.4
2- I would like to see a better mechanism for patching so that we all
know what is patched and I can work on getting those patches
incorporated in the main line.
3- I am working on a way to shorten Apple reaction time and that will
reduce the need for patching
4- I am very open to rethink the bootstrap class. I would like to get
rid of those scripts and I would like the bootstrap class to be able
to load in a jar i.e. being able to launch a WO app by double clicking
it and get the internal jar to load correctly. If someone wants to
work with me on this I am more than happy to share. And yes adding
smarted loading mechanism is a very good idea.
Cheers
Pierre
On Nov 13, 2007, at 1:46, Anjo Krank wrote:
> In case you missed it, 4.0 is the stable branch. From the number of
> people contributing to it, you might guess how large the interest
> for it is. I'm not using it, Mike's not using it, so if you want to
> become the maintainer and invest the time, be my guest. The only
> branch that sees a bit of active development is 2.0 which is what
> the Apple people use internally.
>
> And in case you also missed it: Mike's not using 5.4, I'm not using
> 5.4, both for pretty good reasons. So even *having* a 5.4 build
> right now is mainly us trying to be nice people. But we will not go
> out of our way if people want to build and run on platforms we don't
> use and can't test.
>
> Case in point here was a that Ulrich (unintentionally) broke (part
> of) the launch classpath and we are discussing ways to do better
> than just fix it, possible by a rewrite of the launcher. The core of
> the problem is that in WO, the CP is used for way too many things,
> model loading, framework init order, class discovery, resource
> discovery, property loookup etc.
>
> Therefore I'd suggest we go the launcher road, with some extra flags
> in Info.plist, like the path and init order of the linked
> frameworks. Their Info.plist could hold their linked jars and
> frameworks in turn, thus more closely modeling what Eclipse does
> when starting up. It also opens the way to safer patching, as -
> sorry Pierre - I'm still convinced we'll need it.
>
> Cheers, Anjo
>
> Am 13.11.2007 um 01:17 schrieb Lachlan Deck:
>
>> On 13/11/2007, at 5:04 AM, Mike Schrag wrote:
>>
>>>> Why not fix project Wonder? Instead of this class mangling we
>>>> could make Project Wonder not override core classes and things
>>>> would be a lot simpler. What do you need in Wonder to make this
>>>> happen?
>>> Having Project Wonder not override core classes would just break
>>> the things that PW fixes. Most of the reasons for doing this in
>>> Wonder may be fixed in 5.4 (generic NS*, etc), but I suspect the
>>> vast majority of users are not using 5.4, so we can't just remove
>>> support for them.
>>
>> But you could of course create a stable branch for current users...
>> and then start down this road.
>>
>> with regards,
>> --
>>
>> Lachlan Deck
>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Tue Nov 13 2007 - 11:06:01 EST