Send to Printer

smalltalk

Interesting VW 7.8 Build Problem

September 15, 2011 19:19:59.740

Today I was in the last bit of an update from VW 7.6 to VW 7.8 (the last bit of the major work; I'm sure there will be small stuff popping up for weeks yet). The thing I ran into was in my build tool - it just wouldn't build a working runtime. I assumed it was a problem with my script, so I tried RTP to see if things went differently for me (even though I really dislike RTP...). Lo and behold, it failed the same way, but I managed to get an error log (no idea why my build didn't spit one out, but there it is). This method caused me fits, in SystemEventInterest:


notifyStoreBrowser
	"StoreRefactoringBrowser has an interest in #earlySystemInstallation.   When that event occurs,
	 it will clear out any open browsers."

	

	Store.Glorp.StoreRefactoringBrowser cleanUpObsoleteInstances

I have no idea why that doesn't have an "isRuntime" check in it - and after speaking to some people at Cincom, I learned that it's probably the eventual answer. In any case, I changed it to look like this:


notifyStoreBrowser
	"StoreRefactoringBrowser has an interest in #earlySystemInstallation.   When that event occurs,
	 it will clear out any open browsers."

	

	DeploymentOptionsSystem isRuntime
		ifFalse: [Store.Glorp.StoreRefactoringBrowser cleanUpObsoleteInstances].

Which prevents the message from being sent to the (deleted in a runtime) class. It's always something :)

Technorati Tags: ,

posted by James Robertson

Comments

Re: Interesting VW 7.8 Build Problem

[HolgerK] September 16, 2011 8:22:09.100

Does the application really require the package StoreForGlorpBrowserUI (which contains #notifyStoreBrowser)?

Re: Interesting VW 7.8 Build Problem

[Alan Knight] September 16, 2011 13:24:40.042

It should do something like that, the reason it didn't have it in the first place is probably not expecting people to want to package Store into their runtime images.

Re: Interesting VW 7.8 Build Problem

[James Robertson] September 16, 2011 17:12:27.961

Store stays in the packaged image. At least in 7.6, we found that unloading Store created an unstable runtime for us.

 Share Tweet This