[Seaside] install Seaside30 without OB?
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
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
| version |
version := ConfigurationOfSeaside30 project
((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'
'Seaside-Development' 'JQuery-Core' 'Seaside-HTML5'
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')
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