Hudson build for Seaside too?

OK - we have the hudson build for Pharo Core, Pharo, Moose, ...

Since Pharo is the reference platform for Seaside
wouldnt it make sense to run a hudson build for
Seaside too:


       Gofer new
                squeaksource: 'MetacelloRepository';
                package: 'ConfigurationOfSeaside30';
        load.
       
        ((Smalltalk at: #ConfigurationOfSeaside30) project latestVersion) load.

I know that http://hudson.lukas-renggli.ch/ builds a seaside
one click ... but still on the old Pharo 1.1.

Wouldnt it make sense to have one for Pharo1.2 with Seaside3.0
already. So we can see early when we break things for Seaside ...

Bye
T.



--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

On 3 February 2011 17:04, Torsten Bergmann <[hidden email]> wrote:
+1



--
Best regards,
Igor Stasenko AKA sig.

On Feb 3, 2011, at 5:05 PM, Torsten Bergmann wrote:
Yes, I think this is a good idea. Not for providing an alternative distribution,
but as a nice regression test and a *huge* additional testsuite, this would
be very valuable.

And we can this way coordinate API level changes much better.

I will put it on the list.


    Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

+1
Marcus the hudson master :)

On 03 Feb 2011, at 17:04, Torsten Bergmann wrote:

>       Gofer new
> squeaksource: 'MetacelloRepository';
> package: 'ConfigurationOfSeaside30';
> load.
>
> ((Smalltalk at: #ConfigurationOfSeaside30) project latestVersion) load.

For the last couple of weeks, and again this evening I wanted to start using 1.2 as my main image, but that requires Seaside 3, the above still does not work for me:

Pharo1.2rc2
Latest update: #12330

ConfigurationOfOmnibrowser>>postLoadOBStandard

Preferences DNU #enable

As long as Seaside does not load, I will have to stick with 1.1.1, even if I really would like to switch...
And I am pretty sure I am not the only one

Sven

I find strange that seaside relies on OB.
We should remove this dependency (of course making sure that OB loads is important) but this is another issue.

Stef

Stef,

The Seaside control panel is built on top of OB.

It is entirely possible to deploy a Seaside application without including the Seaside control panel, but you need to know  how to manually configure/start/stop the adaptors. As a result it was decided to include the control panel as part of the default install.

For the purposes of testing Seaside, one could arrange to load everything but the control panel - I could provide you with a load expression that excluded the control panel.

As I think about this it probably is a _good_ to test Seaside against Pharo with and without OB on top of a core image, since Seaside is expected to work in both cases...

Dale

On Feb 3, 2011, at 12:40 PM, Stéphane Ducasse wrote:

On 3 February 2011 22:08, Dale Henrichs <[hidden email]> wrote:
I don't know much details, but i think it is possible with metacello
to say 'load config which not using OB' . Right?



--
Best regards,
Igor Stasenko AKA sig.

Yeap, building groups :).

Yes this is my impression.
Frameworks independence and modularity are always good to have.

Stef

On Feb 3, 2011, at 10:08 PM, Dale Henrichs wrote:

Hudson now build a Seaside image and runs all tests after the Full image 1.2 build:

https://pharo-ic.lille.inria.fr/hudson/job/Seaside%20on%20Pharo%201.2/

TODO: 1.3, after fixing the Full 1.3 build.

        Marcus


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Marcus,

Since I seem to be on a symbolic version kick today, may I suggest that you use symbolic versions for Hudson:

    Gofer new
                squeaksource: 'MetacelloRepository';
                package: 'ConfigurationOfSeaside30';
        load.

    ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load.

when you get a chance ... the above expression can be used for all of your Hudson builds regardless of pharo version.

Dale

On Feb 4, 2011, at 6:36 AM, Marcus Denker wrote:

thanks to educate us!!!!

>    ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load.
>

On Feb 4, 2011, at 4:13 PM, Dale Henrichs wrote:

Done.

> the above expression can be used for all of your Hudson builds regardless of pharo version.


use the same, but it loads then a different *stable* for each version?

and

>    ((Smalltalk at: #ConfigurationOfSeaside30) project version: #unstable) load.


would load the latest code into e.g. 1.3?

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

yes at least this is the idea.

> and
>
>>   ((Smalltalk at: #ConfigurationOfSeaside30) project version: #unstable) load.
>
>
> would load the latest code into e.g. 1.3?

may be #development or bleedingEdge

stef

On Feb 6, 2011, at 12:05 PM, Marcus Denker wrote:

There _could_ be a different version for each platform, so by using #stable you'll always get the version that the developers expect to work.

>
> and
>
>>   ((Smalltalk at: #ConfigurationOfSeaside30) project version: #unstable) load.
>
>
> would load the latest code into e.g. 1.3?


My opinion is that you should use the #stable symbolic version for Pharo1.3 as well. The rule should be:

  - the #stable version is the version that the developers recommend to use on a particular platform/platform version

If no #stable version is defined, then the developers haven't finished their porting job yet.

Just because the underlying platform version may be unstable doesn't mean that all of the configurations targeting Pharo1.3 should define another symbolic version for that means "use me on Pharo1.3" ... Anyone using an unstable platform must be aware that at any point in time there may be a change to the underlying system that may break other software in weird and wonderful ways, so the #stable symbolic version for an unstable version means that the version is the best that the developer has for that version....stable is the moral equivalent of latest version ....

With that in mind, I think that you should modify the script to the following:

  Gofer new
                squeaksource: 'MetacelloRepository';
                package: 'ConfigurationOfSeaside30';
        load.
  [
    ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load.
  ]
    on: (Smalltalk at: #MetacelloVersionDoesNotExistError)
    do: [:ex | Transcript show: 'load skipped because no #stable version available'].

Then if I know (for example) that Seaside3.0 doesn't work on Pharo1.3, I can specify that there is no #stable version for 1.3 and you won't even try to load the code let alone run the tests and have a bunch of failures... of course it also is a clear indication to other folks wondering if Seaside3.0 works on Pharo1.3 that it's not ready yet ...

So to repeat, if there is a #stable version defined for Pharo1.3, then it is expected to work modulo any recent changes to the pharo core ... no #stable version defined means that the developers don't have a version ready to run yet.

Dale