[Seaside-dev] Seaside 3.1 ready

[Dale Henrichs]

Philippe,

Pauls' point of only referencing the specific package dependencies is the correct thing to do. Metacello follows package dependencies so you don't need to list all of the know dependencies ... hitting the root (or roots) of the dependency tree will work just fine ... 

Regarding #bleedingEdge ... I think #bleedingEdge in a baseline for projects that are developed together is correct - that way you can load the latest of all packages in the Seaside31 mega project with one load. 

In the version spec you should use #stable - that way you will get the "latest version of the Seaside (or whatever) that is known to work" when you load the configuration.

Tomorrow I will try to take a look at what you've got and point out anything that looks funky...

BTW, what version of Pharo is Seaside3.1 targeted at? I assume that Squeak, GemStone, etc. ports will come after you release?

Dale

----- Original Message -----
| From: "Philippe Marschall" <philippe.marschall at gmail.com>
| To: "Seaside - developer list" <seaside-dev at lists.squeakfoundation.org>
| Sent: Sunday, May 13, 2012 9:40:21 AM
| Subject: Re: [Seaside-dev] Seaside 3.1 ready
| 
| On Wed, May 9, 2012 at 9:20 AM, Philippe Marschall
| <philippe.marschall at gmail.com> wrote:
| > ...
| >> Regarding the 256 literal limit, would you be amenable to breaking
| >> Seaside3.1 up into smaller chunks? I think that it is high time
| >> that the configuration for Seaside be revisited and revamped
| >>
| >> I have spent zero time looking at Seaside3.1 so I have no idea
| >> that's been going on there, but things like the javascript
| >> support and REST and JSON and Examples and etc. could actually be
| >> managed in separate configurations. Splitting those things out
| >> into separate configurations would not only reduce the number of
| >> literals needed in the monolithic version spec, but would make it
| >> easier for people to understand what is optional and what is
| >> required ...
| >>
| >> What do you say?
| >
| > Sounds interesting. Just to be sure, we'd end up with configuration
| > classes like
| >
| > ConfigurationOfSeaside31
| > ConfigurationOfJQuery
| > ConfigurationOfSeasideRest
| 
| OK, I moved a lot of things in ConfigurationOfSeaside31 to the
| following configurations:
| 
|  - ConfigurationOfJavascript31
|  - ConfigurationOfJQuery31
|  - ConfigurationOfJQueryUI31
|  - ConfigurationOfScriptaculous31 (contains protoype)
|  - ConfigurationOfComet31
|  - ConfigurationOfSeasideRest31
|  - ConfigurationOfJson31
|  - ConfigurationOfRss31
|  - ConfigurationOfSeasideWelcome31 (contains 'OneClick' group)
| 
| ConfigurationOfSeaside31 is still huge though. I tried to give each
| configuration a 'Base', 'Base Tests' and optionally a 'Base Examples'
| group. I common problem I ran into is referring to an other
| configuration. I copied and pasted the following block without really
| understanding what it does:
| 
| spec
| 	project: 'Seaside Core' with: [
| 		spec
| 			className: 'ConfigurationOfSeaside31';
| 			versionString: #'bleedingEdge';
| 			loads: #('Core' );
| 			repository: 'http://www.squeaksource.com/MetacelloRepository' ].
| 
| Does this actually load the 'Core' group of ConfigurationOfSeaside31?
| If so how do I just import package definitions (eg. dependencies on
| 'Seaside-Canvas') from ConfigurationOfSeaside31 especially
| considering
| that since ConfigurationOfSeaside31 is the package it's already
| loaded.
| 
| Cheers
| Philippe
| 
| Cheers
| Philippe
| _______________________________________________
| seaside-dev mailing list
| seaside-dev at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|