Hi Christophe,

Thanks for the answer. I managed to do that!

Am I interpreting something wrong or the CoolBrowser-Platform itself is an 
empty package?

Cheers,
R


> 
On Jun 26, 2014, at 2:08 PM, Christophe Demarey <[email protected]> 
wrote:

> Hi,
> 
> You can find useful information into the 'Deep into Pharo' book, chapter 9 
> (Managing projects with Metacello), section 9.12 (platform specific package).
> 
> Example:
> ConfigurationOfCoolBrowser>>baseline09: spec
> <version: '0.9-baseline'>
> spec for: #common do: [
>       spec blessing: #baseline.
>       spec repository: 'http://www.example.com/CoolBrowser'.
>       spec
>               package: 'CoolBrowser-Core';
>               package: 'CoolBrowser-Tests' with: [ spec requires: 
> 'CoolBrowser-Core' ];
>               package: 'CoolBrowser-Addons' with: [ spec requires: 
> 'CoolBrowser-Core' ];
>               package: 'CoolBrowser-AddonsTests' with: [
>                       spec requires: #('CoolBrowser-Addons' 
> 'CoolBrowser-Tests' ) ].
>       spec
>               group: 'default' with: #('CoolBrowser-Core' 
> 'CoolBrowser-Addons' );
>               group: 'Core' with: #('CoolBrowser-Core' 'CoolBrowser-Platform' 
> );
>               group: 'Extras' with: #('CoolBrowser-Addon');
>               group: 'Tests' with: #('CoolBrowser-Tests' 
> 'CoolBrowser-AddonsTests' );
>               group: 'CompleteWithoutTests' with: #('Core', 'Extras' );
>               group: 'CompleteWithTests' with: #('CompleteWithoutTests', 
> 'Tests' )].
> spec for: #gemstone do: [
>       spec package: 'CoolBrowser-Platform' with: 
> 'CoolBrowser-PlatformGemstone'].
> spec for: #pharo do: [
>       spec package: 'CoolBrowser-Platform' with: 'CoolBrowser-PlatformPharo'].
> 
> Le 26 juin 2014 à 13:43, Roberto Minelli a écrit :
> 
>> Hi,
>> 
>> I have my project with my Configuration and I am using spec groups to load 
>> different sets of packages (e.g., development and user groups).
>> 
>> With the porting to Pharo 4.0 I discovered that there are some 
>> functionalities specific to Pharo 3.0 and others to Pharo 4.0, for example 
>> the fact that MethodContext is no longer part of Pharo 4.0. but it has been 
>> replaced by Context.
>> 
>> I moved such functionalities in a package, say 'MyProject-Extension30’ and 
>> Pharo 4.0 specific functionalities in 'MyProject-Extension40’.
>> 
>> Now the question is, suppose that I have a group like
>> spec group: ‘User' with: #(‘A’ ‘B’ ‘C’).
>> 
>> and another one:
>> spec group: ‘Dev' with: #(‘A’ ‘B’ ‘C’ ‘D’ ‘E’).
>> 
>> Until now, the developer (i.e., me) would do something like
>> (self project version: #bleedingEdge) load: #('Dev’)
>> 
>> and a used of my project would do
>> (self project version: #bleedingEdge) load: #(‘User’)
>> 
>> 
>> 
>> How can I factor inside the dynamic load of the two Pharo-version specific 
>> packages?
>> i.e., no matter if ‘User’ or ‘Dev’ group is loaded I need to load 
>> 'MyProject-Extension40’ if I am on Pharo 4.0 and 'MyProject-Extension30’ if 
>> on Pharo 3.0.
>> 
>> Thanks for your help,
>> Roberto
> 


Reply via email to