[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
> 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
> | 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'
> '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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside