Seaside31 comments

Philippe,

These are my unfiltered comments on the configurations. I want you to take the comments with a grain of salt, because my comments are intended to inform not explicitly criticize. I'll make remarks in detail, but I don't think it is worth it for you to make detailed responses.  I don't intend on spending a lot of time explaining/defending my comments, unless something doesn't make sense to you or you feel strongly ... those are the areas that are worth discussing in my opinon.

There's lots of wiggle room in defining specs so there aren't too many black and white issues ... if the configuration validates cleanly it should be good to go.

I didn't finish looking at all of the specs, but I think I've hit enough of the highlights to get the ball rolling...

Dale

------------General----------------------------------

1. Eventually you will have one package per configuration, instead of all the configurations in one package.

------------ConfigurationOfSeaside31----------------------------------

1. #seaside304DoIts is probably not needed in 31. Include only if you have proven that you need it.

2. you've included a bunch of GemStone packages ... are those know to work or just included from 3.0?

3. The #project method has extra cruft that is no longer needed ... replace with MetacelloBaseConfiguration>>project.

4. Strip the class side development support category... I think there is better toolbox support for the operations ... keep the #validate method.

5. it's worth looking at Versionner to see if it performs the require development operations. Let Juan know if it Versionner needs work...

6. Do you plan on continued support of Swazoo in 3.1?

7. The 'default' group loads 'Core' and 'Tests' are you sure that you want to continue with that? Starting from a blank slate, I would do things differently for Seaside3.1:
  - 'Base' renamed to 'Core' with tests following suit
  - 'default' includes 'Core' only
  - 'Production' to include the "tools recommended for production"
  - Move 'Seaside-HTML5' 'Seaside-Tools-Web' 'Seaside-Swazoo'
    'Seaside-Adaptors-Swazoo' 'Seaside-Tools-OmniBrowser'
    'Seaside-FileSystem' to a separate configuration (tests too)

8. Actually, I'd create ConfigurationOfSeasideCore31 ... it would include all of the packages in the 'Base' package. Most of the packages that depend upon Seaside would reference ConfigurationOfSeasideCore31. 'default' group for this configuration should just be the non-test packages.

9. The ConfigurationOfSeaside31 would then include the packages that are in the current ConfigurationOfSeaside31, but not in ConfigurationOfSeasideCore31...this would probably make it possible to do away with the *commonBaseline: method (created because of 256 literal limit). Group definitions as follows:

  - 'default' includes the "kitchen sink", Tests' and all
    packages since we've separated out the Core to a separate
    configuration
  - 'Core' includes the ConfigurationOfSeasideCore31
  - 'Production' includes ConfigurationOfSeasideCore31 and "tools
    recommended for production"...no 'Tests'
  - 'Development' includes ConfigurationOfSeasideCore31 and development
    packages (excluding 'Seaside-HTML5','Seaside-Tools-Web', etc.), includes
    'Tests'

10. ConfigurationOfSeaside31 would also include references to the other Seaside31 configurations: ConfigurationOfComet31, ConfigurationOfSeasideRest31. etc. Including them here would make it convenient for someone to create a nice load expression that includes everything they want for their project:

  (ConfigurationOfSeaside31 project version: #stable)
    load: #('Production', 'Seaside-Zinc', 'Rest', 'JQuery', 'Seaside-HTML5')

11. You are still including Kom as the default adaptor ... did you want to switch to KomLite or Zinc as the default?

12. 'Comet-Core' 'Comet-Examples' 'Comet-Tests-Core' still included in the baseline310: spec.


------------ConfigurationOfGrease----------------------------------

1. Grease 1.1.0 is defined in the copy of Grease in the Seaside3.1 repository. There needs to be only one _master copy_ of the Grease configuration and that's in the Seaside3.0 repository.

2. ConfigurationOfGrease and the packages will be shared between Seaside3.0 and Seaside3.1.

3. It's not Grease if it has to be forked for Seaside3.1.

4. ConfigurationOfGrease does not validate correctly: #baseline110: is specifying version '1.0.0-baseline' not '1.1.0-baseline'

5. there are additional validation errors after fixing number 4.

6. strip the class-side development support category (keep the #validate method:).


------------ConfigurationOfRss31----------------------------------

1. I now understand what you meant by "look for it in ConfigurationOfSeaside31". Metacello works slightly differently than you think. Here's the recast baseline spec:

baseline310: spec
    <version: '3.1.0-baseline'>
    spec
        for: #'common'
        do: [
            spec blessing: #'baseline'.
            spec description: ''.
            spec repository: 'http://www.squeaksource.com/Seaside31'.
            spec
                project: 'Seaside-Core'
                    with: [
                            spec
                                className: 'ConfigurationOfSeaside31';
                                versionString: #'bleedingEdge';
                                loads: #('Seaside-Canvas');
                                repository: 'http://www.squeaksource.com/MetacelloRepository' ];
                project: 'Seaside-Canvas' copyFrom: 'Seaside-Core' with: [ spec loads: #('Seaside-Canvas') ];
                project: 'Seaside-Tests-Core' copyFrom: 'Seaside-Core' with: [ spec loads: #('Seaside-Tests-Core') ];
                project: 'Seaside-Tools-Core' copyFrom: 'Seaside-Core' with: [ spec loads: #('Seaside-Tools-Core') ].
            spec
                package: 'RSS-Core' with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas') ];
                package: 'RSS-Tests-Core' with: [ spec requires: #('RSS-Core' 'Seaside-Tests-Core') ];
                package: 'RSS-Examples' with: [ spec requires: #('RSS-Core' 'Seaside-Tools-Core') ].
            spec
                group: 'Base' with: #('RSS-Core');
                group: 'Base Tests' with: #('RSS-Tests-Core');
                group: 'Base Examples' with: #('RSS-Examples') ]

And the the version310: would looke like:

version310: spec
    <version: '3.1.0' imports: #('3.1.0-baseline')>
    spec
        for: #'common'
        do: [
            spec blessing: #'release'.
            spec description: 'release 3.1.0 see http://code.google.com/p/seaside/wiki/Seaside310Changelog'.
            spec
                project: 'Seaside-Core' with: '3.1.0';
                project: 'Seaside-Canvas' with: '3.1.0';
                project: 'Seaside-Tests-Core' with: '3.1.0';
                project: 'Seaside-Tools-Core' with: '3.1.0'.
            spec
                package: 'RSS-Core' with: 'RSS-Core-pmm.68';
                package: 'RSS-Examples' with: 'RSS-Examples-lr.26';
                package: 'RSS-Tests-Core' with: 'RSS-Tests-Core-lr.30' ]

a similar technique can be applied to each of the other configurations that reference ConfigurationOfSeaside31.

2. with the above modifications here's what will happen when you load ConfigurationOfRss31:

  (ConfigurationOfRss31 project version: '3.1.0') record: 'Base'
   a MetacelloNullRecordingMCSpecLoader(linear load :
        linear load : 3.1.0 [ConfigurationOfRss31]
                load : ConfigurationOfSeaside31
        linear load : 3.1.0 [ConfigurationOfRss31]
                load : ConfigurationOfSeaside31
        linear load : 3.1.0 [ConfigurationOfRss31]
                linear load : 3.1.0 [ConfigurationOfSeaside31]
                        load : ConfigurationOfGrease
                linear load : 3.1.0 [ConfigurationOfSeaside31]
                        linear load : 1.1.0 [ConfigurationOfGrease]
                                load : Grease-Core-pmm.74
                                load : Grease-Pharo-Core-pmm.52
                                load : Grease-Pharo13-Core
                        load : Seaside-Core-pmm.773
                        load : Seaside-Pharo-Core-pmm.21
                        load : Seaside-Canvas-pmm.122
                        load : Seaside-Pharo-Canvas-pmm.4
                linear load : 3.1.0 [ConfigurationOfSeaside31]
                        linear load : 1.1.0 [ConfigurationOfGrease]
                                load : Grease-Pharo13-Core
                                load : Grease-Tests-Core-pmm.84
                load : RSS-Core-pmm.68)

If one loads Rss31 as currently defined, you will not have a "functional seaside" loaded as not even the 'Base' packages are defined. This means that a developer will have to explicitly load the 'Core'/'Base' group (depending upon which definition we end up with) of Seaside31 to get a "functional seaside".

UNLESS Seaside-Core and Seaside-Canvas CAN function as a standalone unit, in which case the spec is "perfect"...

3. You will want to define a 'default' group for each of the projects. For ConfigurationOfRss31, the 'default' group include 'RSS-Core'

 
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Typo in ConfigurationOfRss31:

            spec
                project: 'Seaside-Core'
                    with: [
                            spec
                                className: 'ConfigurationOfSeaside31';
                                versionString: #'bleedingEdge';
                                loads: #('Seaside-Canvas');
                                repository: 'http://www.squeaksource.com/MetacelloRepository' ];

should be:

            spec
                project: 'Seaside-Core'
                    with: [
                            spec
                                className: 'ConfigurationOfSeaside31';
                                versionString: #'bleedingEdge';
                                loads: #('Seaside-Core');
                                repository: 'http://www.squeaksource.com/MetacelloRepository' ];

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "Seaside - developer list" <[hidden email]>
| Sent: Monday, May 14, 2012 4:56:54 PM
| Subject: [Seaside-dev] Seaside31 comments
|
| Philippe,
|
| These are my unfiltered comments on the configurations. I want you to
| take the comments with a grain of salt, because my comments are
| intended to inform not explicitly criticize. I'll make remarks in
| detail, but I don't think it is worth it for you to make detailed
| responses.  I don't intend on spending a lot of time
| explaining/defending my comments, unless something doesn't make
| sense to you or you feel strongly ... those are the areas that are
| worth discussing in my opinon.
|
| There's lots of wiggle room in defining specs so there aren't too
| many black and white issues ... if the configuration validates
| cleanly it should be good to go.
|
| I didn't finish looking at all of the specs, but I think I've hit
| enough of the highlights to get the ball rolling...
|
| Dale
|
| ------------General----------------------------------
|
| 1. Eventually you will have one package per configuration, instead of
| all the configurations in one package.
|
| ------------ConfigurationOfSeaside31----------------------------------
|
| 1. #seaside304DoIts is probably not needed in 31. Include only if you
| have proven that you need it.
|
| 2. you've included a bunch of GemStone packages ... are those know to
| work or just included from 3.0?
|
| 3. The #project method has extra cruft that is no longer needed ...
| replace with MetacelloBaseConfiguration>>project.
|
| 4. Strip the class side development support category... I think there
| is better toolbox support for the operations ... keep the #validate
| method.
|
| 5. it's worth looking at Versionner to see if it performs the require
| development operations. Let Juan know if it Versionner needs work...
|
| 6. Do you plan on continued support of Swazoo in 3.1?
|
| 7. The 'default' group loads 'Core' and 'Tests' are you sure that you
| want to continue with that? Starting from a blank slate, I would do
| things differently for Seaside3.1:
|   - 'Base' renamed to 'Core' with tests following suit
|   - 'default' includes 'Core' only
|   - 'Production' to include the "tools recommended for production"
|   - Move 'Seaside-HTML5' 'Seaside-Tools-Web' 'Seaside-Swazoo'
|     'Seaside-Adaptors-Swazoo' 'Seaside-Tools-OmniBrowser'
|     'Seaside-FileSystem' to a separate configuration (tests too)
|
| 8. Actually, I'd create ConfigurationOfSeasideCore31 ... it would
| include all of the packages in the 'Base' package. Most of the
| packages that depend upon Seaside would reference
| ConfigurationOfSeasideCore31. 'default' group for this configuration
| should just be the non-test packages.
|
| 9. The ConfigurationOfSeaside31 would then include the packages that
| are in the current ConfigurationOfSeaside31, but not in
| ConfigurationOfSeasideCore31...this would probably make it possible
| to do away with the *commonBaseline: method (created because of 256
| literal limit). Group definitions as follows:
|
|   - 'default' includes the "kitchen sink", Tests' and all
|     packages since we've separated out the Core to a separate
|     configuration
|   - 'Core' includes the ConfigurationOfSeasideCore31
|   - 'Production' includes ConfigurationOfSeasideCore31 and "tools
|     recommended for production"...no 'Tests'
|   - 'Development' includes ConfigurationOfSeasideCore31 and
|   development
|     packages (excluding 'Seaside-HTML5','Seaside-Tools-Web', etc.),
|     includes
|     'Tests'
|
| 10. ConfigurationOfSeaside31 would also include references to the
| other Seaside31 configurations: ConfigurationOfComet31,
| ConfigurationOfSeasideRest31. etc. Including them here would make it
| convenient for someone to create a nice load expression that
| includes everything they want for their project:
|
|   (ConfigurationOfSeaside31 project version: #stable)
|     load: #('Production', 'Seaside-Zinc', 'Rest', 'JQuery',
|     'Seaside-HTML5')
|
| 11. You are still including Kom as the default adaptor ... did you
| want to switch to KomLite or Zinc as the default?
|
| 12. 'Comet-Core' 'Comet-Examples' 'Comet-Tests-Core' still included
| in the baseline310: spec.
|
|
| ------------ConfigurationOfGrease----------------------------------
|
| 1. Grease 1.1.0 is defined in the copy of Grease in the Seaside3.1
| repository. There needs to be only one _master copy_ of the Grease
| configuration and that's in the Seaside3.0 repository.
|
| 2. ConfigurationOfGrease and the packages will be shared between
| Seaside3.0 and Seaside3.1.
|
| 3. It's not Grease if it has to be forked for Seaside3.1.
|
| 4. ConfigurationOfGrease does not validate correctly: #baseline110:
| is specifying version '1.0.0-baseline' not '1.1.0-baseline'
|
| 5. there are additional validation errors after fixing number 4.
|
| 6. strip the class-side development support category (keep the
| #validate method:).
|
|
| ------------ConfigurationOfRss31----------------------------------
|
| 1. I now understand what you meant by "look for it in
| ConfigurationOfSeaside31". Metacello works slightly differently than
| you think. Here's the recast baseline spec:
|
| baseline310: spec
|     <version: '3.1.0-baseline'>
|     spec
|         for: #'common'
|         do: [
|             spec blessing: #'baseline'.
|             spec description: ''.
|             spec repository: 'http://www.squeaksource.com/Seaside31'.
|             spec
|                 project: 'Seaside-Core'
|                     with: [
|                             spec
|                                 className:
|                                 'ConfigurationOfSeaside31';
|                                 versionString: #'bleedingEdge';
|                                 loads: #('Seaside-Canvas');
|                                 repository:
|                                 'http://www.squeaksource.com/MetacelloRepository'
|                                 ];
|                 project: 'Seaside-Canvas' copyFrom: 'Seaside-Core'
|                 with: [ spec loads: #('Seaside-Canvas') ];
|                 project: 'Seaside-Tests-Core' copyFrom:
|                 'Seaside-Core' with: [ spec loads:
|                 #('Seaside-Tests-Core') ];
|                 project: 'Seaside-Tools-Core' copyFrom:
|                 'Seaside-Core' with: [ spec loads:
|                 #('Seaside-Tools-Core') ].
|             spec
|                 package: 'RSS-Core' with: [ spec requires:
|                 #('Seaside-Core' 'Seaside-Canvas') ];
|                 package: 'RSS-Tests-Core' with: [ spec requires:
|                 #('RSS-Core' 'Seaside-Tests-Core') ];
|                 package: 'RSS-Examples' with: [ spec requires:
|                 #('RSS-Core' 'Seaside-Tools-Core') ].
|             spec
|                 group: 'Base' with: #('RSS-Core');
|                 group: 'Base Tests' with: #('RSS-Tests-Core');
|                 group: 'Base Examples' with: #('RSS-Examples') ]
|
| And the the version310: would looke like:
|
| version310: spec
|     <version: '3.1.0' imports: #('3.1.0-baseline')>
|     spec
|         for: #'common'
|         do: [
|             spec blessing: #'release'.
|             spec description: 'release 3.1.0 see
|             http://code.google.com/p/seaside/wiki/Seaside310Changelog'.
|             spec
|                 project: 'Seaside-Core' with: '3.1.0';
|                 project: 'Seaside-Canvas' with: '3.1.0';
|                 project: 'Seaside-Tests-Core' with: '3.1.0';
|                 project: 'Seaside-Tools-Core' with: '3.1.0'.
|             spec
|                 package: 'RSS-Core' with: 'RSS-Core-pmm.68';
|                 package: 'RSS-Examples' with: 'RSS-Examples-lr.26';
|                 package: 'RSS-Tests-Core' with:
|                 'RSS-Tests-Core-lr.30' ]
|
| a similar technique can be applied to each of the other
| configurations that reference ConfigurationOfSeaside31.
|
| 2. with the above modifications here's what will happen when you load
| ConfigurationOfRss31:
|
|   (ConfigurationOfRss31 project version: '3.1.0') record: 'Base'
|    a MetacelloNullRecordingMCSpecLoader(linear load :
| linear load : 3.1.0 [ConfigurationOfRss31]
| load : ConfigurationOfSeaside31
| linear load : 3.1.0 [ConfigurationOfRss31]
| load : ConfigurationOfSeaside31
| linear load : 3.1.0 [ConfigurationOfRss31]
| linear load : 3.1.0 [ConfigurationOfSeaside31]
| load : ConfigurationOfGrease
| linear load : 3.1.0 [ConfigurationOfSeaside31]
| linear load : 1.1.0 [ConfigurationOfGrease]
| load : Grease-Core-pmm.74
| load : Grease-Pharo-Core-pmm.52
| load : Grease-Pharo13-Core
| load : Seaside-Core-pmm.773
| load : Seaside-Pharo-Core-pmm.21
| load : Seaside-Canvas-pmm.122
| load : Seaside-Pharo-Canvas-pmm.4
| linear load : 3.1.0 [ConfigurationOfSeaside31]
| linear load : 1.1.0 [ConfigurationOfGrease]
| load : Grease-Pharo13-Core
| load : Grease-Tests-Core-pmm.84
| load : RSS-Core-pmm.68)
|
| If one loads Rss31 as currently defined, you will not have a
| "functional seaside" loaded as not even the 'Base' packages are
| defined. This means that a developer will have to explicitly load
| the 'Core'/'Base' group (depending upon which definition we end up
| with) of Seaside31 to get a "functional seaside".
|
| UNLESS Seaside-Core and Seaside-Canvas CAN function as a standalone
| unit, in which case the spec is "perfect"...
|
| 3. You will want to define a 'default' group for each of the
| projects. For ConfigurationOfRss31, the 'default' group include
| 'RSS-Core'
|
|  
| _______________________________________________
| seaside-dev mailing list
| [hidden email]
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Tue, May 15, 2012 at 1:56 AM, Dale Henrichs <[hidden email]> wrote:
Thanks, I'll work on it.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Philippe,

If you have any questions at all don't hesitate to drop me a line...

Dale

----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Seaside - developer list" <[hidden email]>
| Sent: Thursday, May 17, 2012 2:45:36 AM
| Subject: Re: [Seaside-dev] Seaside31 comments
|
| On Tue, May 15, 2012 at 1:56 AM, Dale Henrichs <[hidden email]>
| wrote:
| > Philippe,
| >
| > These are my unfiltered comments on the configurations. I want you
| > to take the comments with a grain of salt, because my comments are
| > intended to inform not explicitly criticize. I'll make remarks in
| > detail, but I don't think it is worth it for you to make detailed
| > responses.  I don't intend on spending a lot of time
| > explaining/defending my comments, unless something doesn't make
| > sense to you or you feel strongly ... those are the areas that are
| > worth discussing in my opinon.
| >
| > There's lots of wiggle room in defining specs so there aren't too
| > many black and white issues ... if the configuration validates
| > cleanly it should be good to go.
| >
| > I didn't finish looking at all of the specs, but I think I've hit
| > enough of the highlights to get the ball rolling...
| >
| > Dale
| >
| > ------------General----------------------------------
| >
| > 1. Eventually you will have one package per configuration, instead
| > of all the configurations in one package.
| >
| > ------------ConfigurationOfSeaside31----------------------------------
| >
| > 1. #seaside304DoIts is probably not needed in 31. Include only if
| > you have proven that you need it.
| >
| > 2. you've included a bunch of GemStone packages ... are those know
| > to work or just included from 3.0?
| >
| > 3. The #project method has extra cruft that is no longer needed ...
| > replace with MetacelloBaseConfiguration>>project.
| >
| > 4. Strip the class side development support category... I think
| > there is better toolbox support for the operations ... keep the
| > #validate method.
| >
| > 5. it's worth looking at Versionner to see if it performs the
| > require development operations. Let Juan know if it Versionner
| > needs work...
| >
| > 6. Do you plan on continued support of Swazoo in 3.1?
| >
| > 7. The 'default' group loads 'Core' and 'Tests' are you sure that
| > you want to continue with that? Starting from a blank slate, I
| > would do things differently for Seaside3.1:
| >  - 'Base' renamed to 'Core' with tests following suit
| >  - 'default' includes 'Core' only
| >  - 'Production' to include the "tools recommended for production"
| >  - Move 'Seaside-HTML5' 'Seaside-Tools-Web' 'Seaside-Swazoo'
| >    'Seaside-Adaptors-Swazoo' 'Seaside-Tools-OmniBrowser'
| >    'Seaside-FileSystem' to a separate configuration (tests too)
| >
| > 8. Actually, I'd create ConfigurationOfSeasideCore31 ... it would
| > include all of the packages in the 'Base' package. Most of the
| > packages that depend upon Seaside would reference
| > ConfigurationOfSeasideCore31. 'default' group for this
| > configuration should just be the non-test packages.
| >
| > 9. The ConfigurationOfSeaside31 would then include the packages
| > that are in the current ConfigurationOfSeaside31, but not in
| > ConfigurationOfSeasideCore31...this would probably make it
| > possible to do away with the *commonBaseline: method (created
| > because of 256 literal limit). Group definitions as follows:
| >
| >  - 'default' includes the "kitchen sink", Tests' and all
| >    packages since we've separated out the Core to a separate
| >    configuration
| >  - 'Core' includes the ConfigurationOfSeasideCore31
| >  - 'Production' includes ConfigurationOfSeasideCore31 and "tools
| >    recommended for production"...no 'Tests'
| >  - 'Development' includes ConfigurationOfSeasideCore31 and
| >  development
| >    packages (excluding 'Seaside-HTML5','Seaside-Tools-Web', etc.),
| >    includes
| >    'Tests'
| >
| > 10. ConfigurationOfSeaside31 would also include references to the
| > other Seaside31 configurations: ConfigurationOfComet31,
| > ConfigurationOfSeasideRest31. etc. Including them here would make
| > it convenient for someone to create a nice load expression that
| > includes everything they want for their project:
| >
| >  (ConfigurationOfSeaside31 project version: #stable)
| >    load: #('Production', 'Seaside-Zinc', 'Rest', 'JQuery',
| >    'Seaside-HTML5')
| >
| > 11. You are still including Kom as the default adaptor ... did you
| > want to switch to KomLite or Zinc as the default?
| >
| > 12. 'Comet-Core' 'Comet-Examples' 'Comet-Tests-Core' still included
| > in the baseline310: spec.
| >
| >
| > ------------ConfigurationOfGrease----------------------------------
| >
| > 1. Grease 1.1.0 is defined in the copy of Grease in the Seaside3.1
| > repository. There needs to be only one _master copy_ of the Grease
| > configuration and that's in the Seaside3.0 repository.
| >
| > 2. ConfigurationOfGrease and the packages will be shared between
| > Seaside3.0 and Seaside3.1.
| >
| > 3. It's not Grease if it has to be forked for Seaside3.1.
| >
| > 4. ConfigurationOfGrease does not validate correctly: #baseline110:
| > is specifying version '1.0.0-baseline' not '1.1.0-baseline'
| >
| > 5. there are additional validation errors after fixing number 4.
| >
| > 6. strip the class-side development support category (keep the
| > #validate method:).
| >
| >
| > ------------ConfigurationOfRss31----------------------------------
| >
| > 1. I now understand what you meant by "look for it in
| > ConfigurationOfSeaside31". Metacello works slightly differently
| > than you think. Here's the recast baseline spec:
| >
| > baseline310: spec
| >    <version: '3.1.0-baseline'>
| >    spec
| >        for: #'common'
| >        do: [
| >            spec blessing: #'baseline'.
| >            spec description: ''.
| >            spec repository:
| >            'http://www.squeaksource.com/Seaside31'.
| >            spec
| >                project: 'Seaside-Core'
| >                    with: [
| >                            spec
| >                                className:
| >                                'ConfigurationOfSeaside31';
| >                                versionString: #'bleedingEdge';
| >                                loads: #('Seaside-Canvas');
| >                                repository:
| >                                'http://www.squeaksource.com/MetacelloRepository'
| >                                ];
| >                project: 'Seaside-Canvas' copyFrom: 'Seaside-Core'
| >                with: [ spec loads: #('Seaside-Canvas') ];
| >                project: 'Seaside-Tests-Core' copyFrom:
| >                'Seaside-Core' with: [ spec loads:
| >                #('Seaside-Tests-Core') ];
| >                project: 'Seaside-Tools-Core' copyFrom:
| >                'Seaside-Core' with: [ spec loads:
| >                #('Seaside-Tools-Core') ].
| >            spec
| >                package: 'RSS-Core' with: [ spec requires:
| >                #('Seaside-Core' 'Seaside-Canvas') ];
| >                package: 'RSS-Tests-Core' with: [ spec requires:
| >                #('RSS-Core' 'Seaside-Tests-Core') ];
| >                package: 'RSS-Examples' with: [ spec requires:
| >                #('RSS-Core' 'Seaside-Tools-Core') ].
| >            spec
| >                group: 'Base' with: #('RSS-Core');
| >                group: 'Base Tests' with: #('RSS-Tests-Core');
| >                group: 'Base Examples' with: #('RSS-Examples') ]
| >
| > And the the version310: would looke like:
| >
| > version310: spec
| >    <version: '3.1.0' imports: #('3.1.0-baseline')>
| >    spec
| >        for: #'common'
| >        do: [
| >            spec blessing: #'release'.
| >            spec description: 'release 3.1.0 see
| >            http://code.google.com/p/seaside/wiki/Seaside310Changelog'.
| >            spec
| >                project: 'Seaside-Core' with: '3.1.0';
| >                project: 'Seaside-Canvas' with: '3.1.0';
| >                project: 'Seaside-Tests-Core' with: '3.1.0';
| >                project: 'Seaside-Tools-Core' with: '3.1.0'.
| >            spec
| >                package: 'RSS-Core' with: 'RSS-Core-pmm.68';
| >                package: 'RSS-Examples' with: 'RSS-Examples-lr.26';
| >                package: 'RSS-Tests-Core' with:
| >                'RSS-Tests-Core-lr.30' ]
| >
| > a similar technique can be applied to each of the other
| > configurations that reference ConfigurationOfSeaside31.
| >
| > 2. with the above modifications here's what will happen when you
| > load ConfigurationOfRss31:
| >
| >  (ConfigurationOfRss31 project version: '3.1.0') record: 'Base'
| >   a MetacelloNullRecordingMCSpecLoader(linear load :
| >        linear load : 3.1.0 [ConfigurationOfRss31]
| >                load : ConfigurationOfSeaside31
| >        linear load : 3.1.0 [ConfigurationOfRss31]
| >                load : ConfigurationOfSeaside31
| >        linear load : 3.1.0 [ConfigurationOfRss31]
| >                linear load : 3.1.0 [ConfigurationOfSeaside31]
| >                        load : ConfigurationOfGrease
| >                linear load : 3.1.0 [ConfigurationOfSeaside31]
| >                        linear load : 1.1.0 [ConfigurationOfGrease]
| >                                load : Grease-Core-pmm.74
| >                                load : Grease-Pharo-Core-pmm.52
| >                                load : Grease-Pharo13-Core
| >                        load : Seaside-Core-pmm.773
| >                        load : Seaside-Pharo-Core-pmm.21
| >                        load : Seaside-Canvas-pmm.122
| >                        load : Seaside-Pharo-Canvas-pmm.4
| >                linear load : 3.1.0 [ConfigurationOfSeaside31]
| >                        linear load : 1.1.0 [ConfigurationOfGrease]
| >                                load : Grease-Pharo13-Core
| >                                load : Grease-Tests-Core-pmm.84
| >                load : RSS-Core-pmm.68)
| >
| > If one loads Rss31 as currently defined, you will not have a
| > "functional seaside" loaded as not even the 'Base' packages are
| > defined. This means that a developer will have to explicitly load
| > the 'Core'/'Base' group (depending upon which definition we end up
| > with) of Seaside31 to get a "functional seaside".
| >
| > UNLESS Seaside-Core and Seaside-Canvas CAN function as a standalone
| > unit, in which case the spec is "perfect"...
| >
| > 3. You will want to define a 'default' group for each of the
| > projects. For ConfigurationOfRss31, the 'default' group include
| > 'RSS-Core'
|
| Thanks, I'll work on it.
|
| Cheers
| Philippe
| _______________________________________________
| seaside-dev mailing list
| [hidden email]
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev