[Seaside] install Seaside30 without OB?

Mariano Martinez Peck marianopeck at gmail.com
Wed Jan 5 19:50:11 UTC 2011

On Wed, Jan 5, 2011 at 7:29 PM, Dale Henrichs <dhenrich at vmware.com> wrote:

> On 01/05/2011 07:35 AM, Mariano Martinez Peck wrote:
>> I would not include 'Seaside-Tools' at all in the Core group and I would
>> not put is as default.
>> I would create another group, that incldues the Core + Seaside-Tools +
>> rest of the sutff  and would put that group as default. This fixes the
>> two problems:
>> - newbies do not need to know which group to load and just the default
>> will load the Seaside-Tools and all the necessary packages (probably all
>> of them)
>> - Advanced guys that need core, probably know how to use metacello, and
>> they can just load Core for their images (even maybe only for production
>> images)
>> Cheers
>> mariano
> Mariano, et.al.,
> Seaside30 has so many packages and so many possible _valid_ combinations of
> packages that it didn't make a lot of sense to try to define groups for all
> of the possible combos...

yes, that's true!!!

> It was decided over a long series of emails to create a 'Base' group that
> was the absolute minimum usable chunk of Seaside.
> The 'Core' group was then defined as everything else that came with Seaside
> excluding the tests. Note that the core group includes all of the
> development tools as well...

Hi Dale. This is what is misleading for me. I mean, from my point of view,
development tools are not core. Just watching it form outside, I may call
'core' to what you call now 'base' and try to find a better name for what it
is now in 'Core'.

> The 'OneClick' group was added later to match the content of the 'OneClick'
> image (which basically excluded the LGPL packages) and included many tests.
> Now that there are folks who have some real needs it probably makes sense
> to take another look at creating some finer grained groups.
> So, if you run the following expression in a Pharo image, with the latest
> ConfigurationOfSeaside30:
>  | version  |
>  version := ConfigurationOfSeaside30 project
>    version: '3.0.3-commonBaseline'.
>  ((version packages collect: [:each | each name ]) asSet
>    difference: ((version groups detect: [:each |
>        each name = 'Base']) includes) asSet)
>          reject: [:each | each includesSubString: '-Tests-' ]
> You'll get the list of basic packages that are not included in the 'Base'
> group and are not test packages:
>  'RSS-Core' 'Seaside-InternetExplorer' 'Seaside-Welcome'
>  'Seaside-Email' 'Scriptaculous-Core' 'Seaside-Swazoo'
>  'Javascript-Core' 'Seaside-Adaptors-Swazoo' 'JQuery-UI'
>  'Seaside-Development' 'JQuery-Core' 'Seaside-HTML5'
>  'Seaside-Examples' 'Scriptaculous-Components'
>  'Seaside-Tools-Web' 'Seaside-Tools-OmniBrowser'
>  'Prototype-Core' 'RSS-Examples'
> If reasonable groups can be defined for these packages then we can start
> taking a look at the dependencies involved and go from there.
> If you want to look at the dependencies of the various packages (without
> parsing configurations), you can try printing the results of expressions
> like the following:
>  (ConfigurationOfSeaside30 project version: '3.0.3')
>    record: #('Seaside-Tools-OmniBrowser')
> You'll get a list of the packages that would have been loaded if you did a
> load and the list is in load order...
> Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20110105/2e46d3fb/attachment.htm

More information about the seaside mailing list