New catalog entry for Seaside 3.0.3

> Hi again Seasiders
>
>
> Anfang der weitergeleiteten Nachricht:
>
>> Von: Tobias Pape <[hidden email]>
>> Betreff: [Seaside] Making seaside load in Squeak again.
>> Datum: 26. Februar 2013 09:42:56 MEZ
>> An: Seaside - general discussion <[hidden email]>
>> Kopie: The general-purpose Squeak developers list <[hidden email]>
>> Antwort an: Seaside - general discussion <[hidden email]>
>>
>> Hey Seasiders
>>
>> I am trying to prepare a stable Seaside Image for Squeak 4.4
>> and just tried loading via the Metacello configuration
>> (Like this:
>>
>> Installer ss
>>       project: 'MetacelloRepository';
>>       install: 'ConfigurationOfSeaside30'.
>> ((Smalltalk at: #ConfigurationOfSeaside30 project) version: #stable) load
>>
>> )
>>
>> This fails, as there is a dependency on Zinc #stable in
>> #squeakCommon. Also, I think it is worthwhile to add WebCilent
>> to the Adaptors for, at least, Squeak, if not Pharo, too.
>>
>> I have seen that there is progress for that in the Seaside31 repository,
>> especially for the 3.1 version of Seaside.
>
> In my effort to see what I can do I succeeded in
> Running Seaside 3.1 atop Squeak 4.4 (I needed to bring an interim Grease 1.1.1 version for that)
>
> You load  [1]
>         http://netshed.de/seaside/ConfigurationOfGrease-topa.191.mcz
>         http://netshed.de/seaside/ConfigurationOfSeaside30-topa.415.mcz
> and then you can DoIt
>
> ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.1.0') load: #(Development OmniBrowser Swazoo WebClient Welcome).
> (Smalltalk at: #WAServerAdaptorBrowser) open
>
> in a fresh Squeak4.4-12327.
> (Then rightclick in the Seaside Control Panel and 'Add adaptor', a WebServer Adaptor,
> which uses WebClient. Then go to localhost:8080 and be happy.)
>
> Now I will try to work on Seaside 3.0.
>
>>>
> To any Seaside dev, please consider merging my versions :)
> <<
>
> Best
>         -Tobias
>
> [1] this is no MC repo, I just don't have access to the Seaside Repos and didn't want to pollute
>     any MetacelloRepository.

> Hi Tobias, I made new Community-Supported catalog entries for:
>
>  DynamicBindings ("4.4" and "head")
>  KomHttpServer ("4.4")
>  Grease ("1.1.0" and "head")
>  Sport (already up-to-date, no action taken)
>  Seaside ("3.0.3")
>
> These each consume with single-click (necessary pre-reqs are loaded
> automatically for each package).  Installing the head versions always
> perform a merge, similar to updating trunk packages.
>

> Hi All,
>
> as this thread continues, and I have some cross-post replies, I reply to the initial
> post here, hope you don't mind.
>
> • For SqueakMap things goto [SQMP]
> • Seaside-Developers, please read [SEAS]
> • For Metacello-stuff please goto [MTCL]
>
> Am 27.02.2013 um 03:50 schrieb Chris Muller <[hidden email]>:
>
>> Hi Tobias, I made new Community-Supported catalog entries for:
>>
>>  DynamicBindings ("4.4" and "head")
>>  KomHttpServer ("4.4")
>>  Grease ("1.1.0" and "head")
>>  Sport (already up-to-date, no action taken)
>>  Seaside ("3.0.3")
>>
>> These each consume with single-click (necessary pre-reqs are loaded
>> automatically for each package).  Installing the head versions always
>> perform a merge, similar to updating trunk packages.
>>
>
> [SQMP]
> I have read the SqueakMap entries.
>
> From my point of view, they pose a quite big problem.
>
> Please consider this Scenario:
>
> For one reason or another, I happen to have the Class `GRPlaform`
> in my image but not actually Grease installed. Now suppose I
> use the SqueakMap entry for Seaside. It installs but fails with
> —seemingly random—errors.
>   What happens here? The install _script_ for Seaside tries to
> determine whether Grease is installed by checking whether the
> class `GRPlatform` is in the System. Yes, this is a pathological
> case but I chose it to illustrate the underlying problem:
>
> The SqueakMap install scripts are _imperative_ load scripts.
> That is one of the key points of Metacello. To quote
> the web site:
> Declarative modeling. A Metacello project has named versions
> consisting of lists of explicit Monticello package versions. Dependencies
> are explicitly expressed in terms of named versions of required projects.
> A required project is a reference to another Metacello project.
>
> In the given case, when I install Seaside via the Metacello configuration,
> the Seaside config specifies a dependency on Grease declaratively and
> Metacello resolves this. In turn, Grease comes with a Metacello config
> and Metacello then can determine whether Grease is already installed
> via Metacello.
>   In our case, it would determine that Grease is not installed and
> would try to install it. _This_ certainly would fail, as our `GRPlatform`
> class would conflict the one of Grease, but at least we would _know_
> that this is the problem: Monticello would notify us that we are trying
> to overwrite an  existing class.
>
>
> What I wanted to depict is that there is a problem with the “install script”
> driven approach to SqueakMap. I do not argue that SqueakMap is obsolete
> nor a bad idea. I, however, want to argue that SqueakMap should embrace
> Metacello.
>
> Another point I have seen is that SqueakMap has to invest double effort
> to “synchronize” versions.
>   See, Metacello configurations already contain all versions available for
> the given configuration.
>   Moreover, using the current way of SqueakMap to install software conflicts
> with the idea of optional software components. This can be seen by the
> problems Hannes has with installing Seaside [1]. The SqueakMap entry
> cannot disambiguate between a “Development” installation and a “Deployment”
> installation; the Metacello config for Seaside already allows for this:
>    When you load the 'Development' group, you get OB, Ocompletion, the
> server adaptor browser, Seaside development tools, some predefined adaptors
> etc. When you load the “default” group (alias for the “Base” group), you
> get the bare minimum to make Seaside run, even without any adaptor, which
> is intentional. You choose the “Base” group and, say, the “Comanche” group
> and you get what is necessary to run. I don’t see a way to do this with
> SqeuakMap currently.
>   However, this workflow is crucial to me. I maintain SqueakSource3[2] which
> also has optional packages. With SqueakMap, I currently cannot provide
> an installation with such optional packages. Likewise with SwaLint.
>
>
>> I didn't know what version to make for DynamicBindings and
>> KomHttpServer so I just made them the same as the Squeak version
>> they're for.
>
> There is an ConfigurationOfKomHttpServer that could be used..
>
>>
>> I didn't make head versions of KomHttpServer or Seaside because I
>> wanted to ask your (and others') opinions about it.  If Seaside
>> Development Team is still putting out Squeak versions and using
>> Metacello to keep that managed, our catalog entries should definitely
>> reflect that.
>
> Yes:) Where I could help, I would like to.
>
>>  Otherwise, it's worth asking, what is the best way for
>> us as a community to keep up a dependably working version of Seaside
>> for Squeak?
>>
>> Do you know why the Metacello scripts keep failing for stuff that was
>> once working?
>>
>
> [SEAS]
> As dale said in [3]
>
> “If I'm not mistaken the "Metacello failures" are due to the fact
> that new configurations created for Seaside but are not actually tested
> against Squeak until someone (like Tobias) comes along and gives them a try
> ... there hasn't been an official squeak maintainer for Seaside for
> several years now...”
>
> I am currently looking into making Seaside loadable again by
> taking care that the ConfigruationOfSeaside30 has the right
> dependencies for Squeak 4.4
>
> To repeaat myself:
>
>>>
>>> You load  [1]
>>>        http://netshed.de/seaside/ConfigurationOfGrease-topa.191.mcz
>>>        http://netshed.de/seaside/ConfigurationOfSeaside30-topa.415.mcz
>>> […]
> ===========>
>>> To any Seaside dev, please consider merging my versions :)
> <==========
>
> [MTCL]
> Side-Note: Metacello does not yet know of 4.3, 4.4 and 4.5 (as
> our current trunk) as Platform Identifiers. How shall we proceed?
> Who can add these?
>
> Sorry for this being so long, but this is rather important to me.
> I am open for discussion and directions. What about an IRC chat,
> eg, on freenode?
>
> Best
> -Tobias
>
>
>
> [1] Message-Id: <[hidden email]>
> [2] PS: I tried searching the SqueakMap Catalogue for “Squeaksource”, however, nearly
>     every package matched. Shouldn’t the search box only match the name and, optionally,
>     the description but _not_ the installation source?
> [3] Message-ID: <[hidden email]>
>

>
> On Wed, Mar 6, 2013 at 6:21 PM, Dale Henrichs <[hidden email]> wrote:
>> Chris,
>>
>> I think that the officially correct script is the configuration ....
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Chris Muller" <[hidden email]>
>> | To: "Dale Henrichs" <[hidden email]>
>> | Cc: "Seaside - general discussion" <[hidden email]>, "The general-purpose Squeak developers list"
>> | <[hidden email]>
>> | Sent: Tuesday, March 5, 2013 7:24:56 PM
>> | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3
>> |
>> | > to get a working one-click script recorded there that can do it.
>> |
>> | Not only just working, but the officially-correct script
>> |