Seaside 3.1 ready
Locked
 
|
Hi
I feel Seaside 3.1 ready for release [1] - apart from the usual refactorings and cleanups we managed to fix 2 of the 3 major regressions in 3.0 [2] - session continuations are now WARequestHandlers - we have a new WAPluggableActionContinuation - the session tracking code has been refactored, it's simpler and supports new features - document handlers are no longer stored as sessions - JSON support has been updated - HTML5 support has been updated What's missing right now are Metacello configurations. I started working on them but would welcome help. I updated ConfigurationOfGrease to version 1.1, that was easy but the GemStone versions of course still point to 1.0.7. I did not rename it to ConfigurationOfGrease11. Dale, should I rename this? I started a Seaside configuration named ConfigurationOfSeaside31. Dale, is this OK our should I name it ConfigurationOfSeaside30? This is a bit more problematic, because I run into the 256 literal limit in #version310:. I did not add the new packages Seaside-JSON-Core, JQuery-JSON and Seaside-REST to any group. Dale, tell we how you want this done and I'll do it. [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog [2] http://code.google.com/p/seaside/wiki/BigIssues Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Philippe,
Hmmmm, I don't have a lot of extra time right now, to port Seaside3.1 to GemStone and build configurations:( Some advance warning would have been nice... If I'd known you were aiming for a release in this time frame...ah, well... 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? Dale ----- Original Message ----- | From: "Philippe Marschall" <[hidden email]> | To: "Seaside - developer list" <[hidden email]> | Sent: Tuesday, May 8, 2012 11:51:52 AM | Subject: [Seaside-dev] Seaside 3.1 ready | | Hi | | I feel Seaside 3.1 ready for release [1] | - apart from the usual refactorings and cleanups we managed to fix 2 | of the 3 major regressions in 3.0 [2] | - session continuations are now WARequestHandlers | - we have a new WAPluggableActionContinuation | - the session tracking code has been refactored, it's simpler and | supports new features | - document handlers are no longer stored as sessions | - JSON support has been updated | - HTML5 support has been updated | | What's missing right now are Metacello configurations. I started | working on them but would welcome help. | | I updated ConfigurationOfGrease to version 1.1, that was easy but the | GemStone versions of course still point to 1.0.7. I did not rename it | to ConfigurationOfGrease11. Dale, should I rename this? | | I started a Seaside configuration named ConfigurationOfSeaside31. | Dale, is this OK our should I name it ConfigurationOfSeaside30? This | is a bit more problematic, because I run into the 256 literal limit | in | #version310:. I did not add the new packages Seaside-JSON-Core, | JQuery-JSON and Seaside-REST to any group. Dale, tell we how you want | this done and I'll do it. | | [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog | [2] http://code.google.com/p/seaside/wiki/BigIssues | | 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 |
|
|
The jenkins build scripts for Seaside3.1 are split into a number of sections and each of those sections could become a separate configuration (with some tweaks) ... it would definitely be really good starting point ... the configurations should reflect your logical view of the system ...
Dale ----- Original Message ----- | From: "Dale Henrichs" <[hidden email]> | To: "Seaside - developer list" <[hidden email]> | Sent: Tuesday, May 8, 2012 1:08:10 PM | Subject: Re: [Seaside-dev] Seaside 3.1 ready | | Philippe, | | Hmmmm, I don't have a lot of extra time right now, to port Seaside3.1 | to GemStone and build configurations:( Some advance warning would | have been nice... If I'd known you were aiming for a release in this | time frame...ah, well... | | 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? | | Dale | | ----- Original Message ----- | | From: "Philippe Marschall" <[hidden email]> | | To: "Seaside - developer list" | | <[hidden email]> | | Sent: Tuesday, May 8, 2012 11:51:52 AM | | Subject: [Seaside-dev] Seaside 3.1 ready | | | | Hi | | | | I feel Seaside 3.1 ready for release [1] | | - apart from the usual refactorings and cleanups we managed to fix | | 2 | | of the 3 major regressions in 3.0 [2] | | - session continuations are now WARequestHandlers | | - we have a new WAPluggableActionContinuation | | - the session tracking code has been refactored, it's simpler and | | supports new features | | - document handlers are no longer stored as sessions | | - JSON support has been updated | | - HTML5 support has been updated | | | | What's missing right now are Metacello configurations. I started | | working on them but would welcome help. | | | | I updated ConfigurationOfGrease to version 1.1, that was easy but | | the | | GemStone versions of course still point to 1.0.7. I did not rename | | it | | to ConfigurationOfGrease11. Dale, should I rename this? | | | | I started a Seaside configuration named ConfigurationOfSeaside31. | | Dale, is this OK our should I name it ConfigurationOfSeaside30? | | This | | is a bit more problematic, because I run into the 256 literal limit | | in | | #version310:. I did not add the new packages Seaside-JSON-Core, | | JQuery-JSON and Seaside-REST to any group. Dale, tell we how you | | want | | this done and I'll do it. | | | | [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog | | [2] http://code.google.com/p/seaside/wiki/BigIssues | | | | 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 | _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Dale Henrichs
On Tue, May 8, 2012 at 10:08 PM, Dale Henrichs <[hidden email]> wrote:
> Philippe, > > Hmmmm, I don't have a lot of extra time right now, to port Seaside3.1 to GemStone and build configurations:( Some advance warning would have been nice... If I'd known you were aiming for a release in this time frame...ah, well... Sorry about that. There is a slight chance that the existing code just works. > 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 Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
----- Original Message ----- | From: "Philippe Marschall" <[hidden email]> | To: "Seaside - developer list" <[hidden email]> | Sent: Wednesday, May 9, 2012 12:20:23 AM | Subject: Re: [Seaside-dev] Seaside 3.1 ready | | On Tue, May 8, 2012 at 10:08 PM, Dale Henrichs <[hidden email]> | wrote: | > Philippe, | > | > Hmmmm, I don't have a lot of extra time right now, to port | > Seaside3.1 to GemStone and build configurations:( Some advance | > warning would have been nice... If I'd known you were aiming for a | > release in this time frame...ah, well... | | Sorry about that. There is a slight chance that the existing code | just works. | I've branched a Seaside-Core and one or two other packages, so the "just works" depends upon how different 3.1 is ... Speaking of differences: will it be possible to upgrade from Seaside30 to Seaside31? | > 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 Yeah, that would be the idea ... if JQuery and SeasideRest are bound to a particular Seaside3x version then you might find it useful to include 31 in the name... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On Wed, May 9, 2012 at 5:14 PM, Dale Henrichs <[hidden email]> wrote:
> > > ----- Original Message ----- > | From: "Philippe Marschall" <[hidden email]> > | To: "Seaside - developer list" <[hidden email]> > | Sent: Wednesday, May 9, 2012 12:20:23 AM > | Subject: Re: [Seaside-dev] Seaside 3.1 ready > | > | On Tue, May 8, 2012 at 10:08 PM, Dale Henrichs <[hidden email]> > | wrote: > | > Philippe, > | > > | > Hmmmm, I don't have a lot of extra time right now, to port > | > Seaside3.1 to GemStone and build configurations:( Some advance > | > warning would have been nice... If I'd known you were aiming for a > | > release in this time frame...ah, well... > | > | Sorry about that. There is a slight chance that the existing code > | just works. > | > > I've branched a Seaside-Core and one or two other packages, so the "just works" depends upon how different 3.1 is ... Not that much different [1]. There are new methods on GRPlatform but they have default implementations. There's now a cache on WASession for the document handlers. That's what comes to mind. > Speaking of differences: will it be possible to upgrade from Seaside30 to Seaside31? Hard to tell. In theory yes, but then I haven't actually tried it. You surely need to get rid of sessions first and reset application configurations. Apart from that, I don't really know. > | > 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 > > Yeah, that would be the idea ... if JQuery and SeasideRest are bound to a particular Seaside3x version then you might find it useful to include 31 in the name... IC, thanks. [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog#Porters Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Philippe Marschall
On Wed, May 9, 2012 at 9:20 AM, Philippe Marschall
<[hidden email]> 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 [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
On 05/13/2012 09:40 AM, Philippe Marschall wrote:
> 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. I think in your ConfigurationOfXXX if you wanted to load 'Seaside-Canvas' and its dependencies (whether that overlaps 'Core' or not) from the ConfigurationOfSeaside31 you would put: spec project: 'Seaside Canvas' with: [ spec className: 'ConfigurationOfSeaside31'; versionString: #'bleedingEdge'; loads: #('Seaside-Canvas'); repository: 'http://www.squeaksource.com/MetacelloRepository' ]. And I think you don't want versionString: #'bleedingEdge'; either because at some point in time in the future the #'bleedingEdge' could be a different package than what it is today and instead you want versionString: #stable; Paul _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Philippe Marschall
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" <[hidden email]> | To: "Seaside - developer list" <[hidden email]> | 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 | <[hidden email]> 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 | [hidden email] | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
In reply to this post by Paul DeBruicker
On Sun, May 13, 2012 at 7:40 PM, Paul DeBruicker <[hidden email]> wrote:
> On 05/13/2012 09:40 AM, Philippe Marschall wrote: >> >> 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. > > > > I think in your ConfigurationOfXXX if you wanted to load 'Seaside-Canvas' > and its dependencies (whether that overlaps 'Core' or not) from the > ConfigurationOfSeaside31 you would put: > > > spec > project: 'Seaside Canvas' with: [ > > spec > className: 'ConfigurationOfSeaside31'; > versionString: #'bleedingEdge'; > loads: #('Seaside-Canvas'); > repository: > 'http://www.squeaksource.com/MetacelloRepository' ]. > > > And I think you don't want > > versionString: #'bleedingEdge'; > > either because at some point in time in the future the #'bleedingEdge' > could be a different package than what it is today and instead you want > > versionString: #stable; This isn't really what I want to express. What I want to express is: "If you find a package you don't know look for it in ConfigurationOfSeaside31." The #'bleedingEdge' / #stable doesn't really concern me. We're just talking about the baseline, I set it to a specific version in the version. Cheers Philippe _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
|
|
Philippe,
"If you find a package you don't know look for it in ConfigurationOfSeaside31." Who is 'you'? How do 'you' have a 'package you don't know'? Paul gave you the "proper Metacello answer" for how to use project references, perhaps you should describe in more detail what you are trying to do... Dale ----- Original Message ----- | From: "Philippe Marschall" <[hidden email]> | To: "Seaside - developer list" <[hidden email]> | Sent: Monday, May 14, 2012 12:25:18 PM | Subject: Re: [Seaside-dev] Seaside 3.1 ready | | On Sun, May 13, 2012 at 7:40 PM, Paul DeBruicker <[hidden email]> | wrote: | > On 05/13/2012 09:40 AM, Philippe Marschall wrote: | >> | >> 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. | > | > | > | > I think in your ConfigurationOfXXX if you wanted to load | > 'Seaside-Canvas' | > and its dependencies (whether that overlaps 'Core' or not) from the | > ConfigurationOfSeaside31 you would put: | > | > | > spec | > project: 'Seaside Canvas' with: [ | > | > spec | > className: 'ConfigurationOfSeaside31'; | > versionString: #'bleedingEdge'; | > loads: #('Seaside-Canvas'); | > repository: | > 'http://www.squeaksource.com/MetacelloRepository' ]. | > | > | > And I think you don't want | > | > versionString: #'bleedingEdge'; | > | > either because at some point in time in the future the | > #'bleedingEdge' | > could be a different package than what it is today and instead you | > want | > | > versionString: #stable; | | This isn't really what I want to express. What I want to express is: | | "If you find a package you don't know look for it in | ConfigurationOfSeaside31." | | The #'bleedingEdge' / #stable doesn't really concern me. We're just | talking about the baseline, I set it to a specific version in the | version. | | 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 |
|
|
BTW, I'll take a pass through the configurations this afternoon so perhaps I'll get some insight into this when I look at and critique specific configurations...
Dale ----- Original Message ----- | From: "Dale Henrichs" <[hidden email]> | To: "Seaside - developer list" <[hidden email]> | Sent: Monday, May 14, 2012 1:00:58 PM | Subject: Re: [Seaside-dev] Seaside 3.1 ready | | Philippe, | | "If you find a package you don't know look for it in | ConfigurationOfSeaside31." | | Who is 'you'? | | How do 'you' have a 'package you don't know'? | | Paul gave you the "proper Metacello answer" for how to use project | references, perhaps you should describe in more detail what you are | trying to do... | | Dale | | ----- Original Message ----- | | From: "Philippe Marschall" <[hidden email]> | | To: "Seaside - developer list" | | <[hidden email]> | | Sent: Monday, May 14, 2012 12:25:18 PM | | Subject: Re: [Seaside-dev] Seaside 3.1 ready | | | | On Sun, May 13, 2012 at 7:40 PM, Paul DeBruicker | | <[hidden email]> | | wrote: | | > On 05/13/2012 09:40 AM, Philippe Marschall wrote: | | >> | | >> 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. | | > | | > | | > | | > I think in your ConfigurationOfXXX if you wanted to load | | > 'Seaside-Canvas' | | > and its dependencies (whether that overlaps 'Core' or not) from | | > the | | > ConfigurationOfSeaside31 you would put: | | > | | > | | > spec | | > project: 'Seaside Canvas' with: [ | | > | | > spec | | > className: 'ConfigurationOfSeaside31'; | | > versionString: #'bleedingEdge'; | | > loads: #('Seaside-Canvas'); | | > repository: | | > 'http://www.squeaksource.com/MetacelloRepository' ]. | | > | | > | | > And I think you don't want | | > | | > versionString: #'bleedingEdge'; | | > | | > either because at some point in time in the future the | | > #'bleedingEdge' | | > could be a different package than what it is today and instead | | > you | | > want | | > | | > versionString: #stable; | | | | This isn't really what I want to express. What I want to express | | is: | | | | "If you find a package you don't know look for it in | | ConfigurationOfSeaside31." | | | | The #'bleedingEdge' / #stable doesn't really concern me. We're | | just | | talking about the baseline, I set it to a specific version in the | | version. | | | | 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 | _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |