[squeak-dev] Seaside, Squeak4.4, SqueakMap and Metacello, or
Why Software Configuration Management is Important (war: Re: [Seaside]
New catalog entry for Seaside 3.0.3)
janko.mivsek at eranova.si
Wed Mar 6 09:54:18 UTC 2013
Yes, please please, start using Metacello for loading from SqueakMap
too. This way many hours will be spared to us maintainers while
preparing new releases, testing and publishing them an all those
Dne 06. 03. 2013 10:30, piše Tobias Pape:
> 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 <asqueaker at gmail.com>:
>> 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.
> 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
> 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 . 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 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?
> As dale said in 
> “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 
>>> To any Seaside dev, please consider merging my versions :)
> 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?
>  Message-Id: <CAGQxfViuK97mApjNX+ANQo3FieoXJ749ebF6wp+Rt2r890LC8A at mail.gmail.com>
>  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?
>  Message-ID: <454120174.8769768.1362164125368.JavaMail.root at vmware.com>
Smalltalk Web Application Server
More information about the seaside