[Seaside] install Seaside30 without OB?

Dale Henrichs dhenrich at vmware.com
Wed Jan 5 18:29:01 UTC 2011

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...

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...

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...


More information about the seaside mailing list