I would of course like to update the names to remove the whitespace
and be more modern and conventional; these names were chosen long
before these conventions materialized, and since I'm a human, I chose
to use whitespace at that time.  Wish I hadn't or the software had
told me I shouldn't..

I want to see if I can coax MC into letting "Magma client-cmm.123" be
the ancestor of "MagmaClient-Core-cmm.124" without any problems or
side-effects...

 - Chris


On Fri, Apr 15, 2011 at 3:41 PM, Dale Henrichs <dhenrich at vmware.com> wrote:
>
> Miguel's suggestions look okay. Seaside has a slightly different naming
> convention (http://code.google.com/p/seaside/wiki/PackageNaming) that looks
> like the following:
>
> MagmaClient-Core
> MagmaClient-Squeak-Core
> MagmaClient-Pharo-Core
>
> MagmaClient-Tests-Core
> MagmaClient-Tests-Squeak-Core
> MagmaClient-Tests-Pharo-Core
>
> Dale
>
> On 04/15/2011 12:51 PM, Miguel Cobá wrote:
>>
>> This may help
>>
>> http://code.google.com/p/seaside/wiki/PackageNaming.
>>
>> Also, if you are repackaging Magma, it would be marvelous to eliminate
>> whitespace from names, if possible.
>>
>> e.g.
>>
>> MagmaClient-Core
>> MagmaClient-Squeak
>> MagmaClient-Pharo
>> MagmaClient-Tests-Common
>> MagmaClient-Tests-Squeak
>> MagmaClient-Tests-Pharo
>> MagmaServer-Core
>> MagmaServer-Squeak
>> MagmaServer-Pharo
>> MagmaServer-Tests-Common
>> MagmaServer-Tests-Squeak
>> MagmaServer-Tests-Pharo
>>
>> Of course most those packages are almost never needed and will be only
>> created if needed to do something different for a given platform that is
>> used by upper layers. But you get the idea.
>>
>> El vie, 15-04-2011 a las 14:24 -0500, Chris Muller escribió:
>>>
>>> What is the best-practice for structuring a collection of MC packages
>>> containing for platform-independent portions?
>>>
>>> For example, I currently have "Magma client' which has code specific
>>> to Squeak.  So I made a new package:
>>>
>>>   Magma client-Squeak
>>>
>>> And then renamed the method-extension category from "*magma client" to
>>> "*magma client-squeak".
>>>
>>> Unfortunately, PackageInfo considers #isYourClassExtension: to be true
>>> even if only the "core" package name matches the _prefix_ of the
>>> extension category name ("*magma client-squeak"), causing those
>>> extensions end up in two packages; "Magma client" as well as "Magma
>>> client-Squeak".
>>>
>>
>
>
>