[Pharo-project] Category Renaming under Monticello
Hi, When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition. I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one. I also wanted to rename a category, but that would give the same issue I guess. I am sure this is worth a FAQ entry, but I could find anything. Anyone any idea ? Thx, Sven
On Dec 6, 2010, at 3:38 22PM, Sven Van Caekenberghe wrote:
Hi,
When I rename a category, Monticello does not seem to pick up the necessary (class definition) changes, even when I manually accept each class definition.
I was hoping to use category renaming to move some classes out of an MC package and into a seperate new one.
I also wanted to rename a category, but that would give the same issue I guess.
I am sure this is worth a FAQ entry, but I could find anything.
Anyone any idea ?
Thx,
Sven IIRC, Monticello does not automatically create new packages (or delete empty ones) based on recategorization. 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.
Cheers, Henry
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
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
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
Hi, A while ago (2-3 years) I submitted the a change to MC and MC Browser to support package renaming and also changing the initials of all classes in the package. It was rejected because it is possible to have a cleaner alternative implementation that makes use of RB. Unfortunately, I didn't manage to do the change. Attached my code. A right click on a package name is supposed to Note however that I didn't test it with recent Pharo images. Noury On 7 déc. 2010, at 00:05, Sven Van Caekenberghe wrote:
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
participants (3)
-
Henrik Johansen -
Noury Bouraqadi -
Sven Van Caekenberghe