On Monday 28 July 2003 07:52 am, Ned Konz wrote:
> On Sunday 27 July 2003 06:06 pm, Andreas Raab wrote:
> > Honestly, I was very close to the point of setting up my own
> > internal packaging for B3D today. If you can't rely on the
> > interfaces of a packaging system you got a real problem.
>
> You know, we could quite easily make a "stub" package for loading
> .mcv files, for those cases where someone didn't want to load all
> of Monticello.
>
> It would understand the declarations that end up in a .mcv file.
>
> And it could even take care of removals (that is, we'd remove the
> whole package first).

I *think* that all we'd have to do is this:

1. Make a stub .cs with trivial versions of the following that do the 
right thing:

MCClassDefinition>>name:superclassName:category:instVarNames:classVarNames:poolDictionaryNames:classInstVarNames:comment:
	define a class

MCPackage>>named:
	this one would clear out any prior package contents, so it would deal 
with removals OK

MCVersionInfo>>fromArray:
	ignore or save in a global somewhere?

MCMethodDefinition>>className:selector:category:timeStamp:source:
MCMethodDefinition>>className:classIsMeta:true 
selector:category:timeStamp:source:
	define methods

MCOrganizationDefinition>>categories:
	define organization

2. Package .mcv files in SARs with the above stub (optional)

3. Have the SARInstaller know to look for the stub when loading .mcv 
files if the user doesn't want to or can't load Monticello from 
SqueakMap

4. SARInstaller could alternatively load the stub from SqueakMap

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE