Am 29.01.2012 02:46, schrieb James Robertson:
> We start from visual.im
>
> -- load Store tools
> -- load application code
> -- save development image
> -- build runtime image, save it
> -- compress the runtime (using VW tools)
> -- run tests, report on results
> -- copy all final files (dev image, runtimes, and reports) to a share drive location
> -- send email to specified recipient as to build results
>
>
In the VA Smalltalk project that I've been working in for more than 10 years, we've been doing something similar for
quite a long time (not from the beginning, but at least 5-6 years). There's one builder image (which is created by
loading just one app into a virgin VAST image) which is started from a batch file passing the relevant parameters which
specify what config maps should be loaded, what if any tests should be run and whether a runtime image should be built.
This image is being used by a number of small batch files for unit tests and runtime image construction. It's not
automated yet (mostly because I can't be bothered with finding out how to set up repeating jobs on Windows), but running
it is just a matter of double-clicking on a batch file, so it's not a big deal.
Of course, with ENVY you get very powerful version control, so this project could successfully be built by about 20
developers, at that time targeting OS/2 and VAST 6.0, and has been pushed through several VAST versions, survived a
target platform change to Windows, has been extended to include functionality previously supplied by an additional
software system which was unavailable for reasons I won't go into here.
Although this is not a "huge" project it shows that projects with a significant number of developers can be developed
robustly in Smalltalk.
The image is definitely not a problem for us - during development, it's very handy to always have everything available
in the morning just as you left it when going home, and for deployment it's just another way of packaging the
application. Much easier than, say, Java apps which consist of oodles of .jar files and xml configurations and whatever.

I have always been under the impression that the obstacles to using Smalltalk in many organization are a combination of
badmouthing, misinformation, histories of bad licensing policies and perceived vendor instabilities. The PPS/Digitalk
merger, although it is clearly history, did its thing, as well as the Instantiations phoenix-from-the-ashes stunt.

What can one do about it? Seriously, I don't have an answer. We're mostly technical guys, and those normally don't have
a say in the decisions about project tools. I'd be interested in seeing analyses of large Smalltalk projects and the
reason they either succeeded or floundered. What were the actual reasons for DabbleDB to go under, why couldn't
Teleplace make enough money to survive, ...? Was it the technology, or was it that companies initiated by mostly
technical people have a hard time surviving when facing economical upheaval?

Cheers,
Hans-Martin