Hendrik, Thanks for all the help. It seems that changing the category programmatically like this works: ((SystemOrganization listAtCategoryNamed: 'Zinc-HTTP-New-Client-Server') collect: [ :className | Smalltalk globals at: className ]) do: [ :each | each category: 'Zinc-HTTP-Client-Server' ] Now MC did pick up the changes. Sven On 06 Dec 2010, at 16:07, Henrik Johansen wrote:
On Dec 6, 2010, at 3:52 08PM, Sven Van Caekenberghe wrote:
On 06 Dec 2010, at 15:42, Henrik Johansen wrote:
If you create a new package with the proper name in the monticello browser (+Package) though, the recategorized class definitions should end up in the correct place.
OK, Hendrik, +Package might indeed add them to a new Package, and yes one has to do that manually (no problem there), but are they then removed from their original Package ?
And what about just renaming a category, these changes do not seem to be picked up. Is there a way to force this ?
Or do I have to do a fileout and manually delete each class, even edit the fileout's source code ?
Anyway, thanks for the reply.
Sven
IIRC, (big if), the package corresponding to the category that was renamed will not contain any code if you browse it, but neither is it marked as dirty. So by default, you probably wouldn't publish the new, empty version of the package unless you looked for it specifically. New packages created before or after renaming an existing category will not be marked dirty as a consequence of the category rename either.
If you change the category of a single class however, both old and new package will be marked dirty. (Except if you create the new package after performing the rename)
TLDR; The packages will contain the correct code, if you publish them. Marking packages as dirty does not work for category renames, but do work for single class renaming done by recompiling class definition.
Cheers, Henry