1 Oct
2009
1 Oct
'09
10:42 a.m.
Repackaging Moose is envisaged, but it's not gonna
be very easy. By the way,
I tried the 'rename package' refactoring and it didnt quite work as
expected: it creates a new package with the name, but classes (and class
extensions) remain in the old package. Also it does some tricks in
Monticello so that the new package seems to appear as a version with
ancestors (it seems a bit magic to me, but perhaps MC supports package
renaming)
I don't know of such a refactoring, where is that? MC definitely does
not support package renaming.
In Seaside we use the following code. It automates most of the tasks
required to rename a package. However, as all the other Montciello
tools, it will give unexpected results when used on a bogus package
structure. It could work if you rename the packages with the longest
name (the innermost in the set of entities) first, and then continue
with the shorter ones.
WADevelopment class>>renamePackage: oldPackageName to: newPackageName
"self renamePackage: 'Seaside-Squeak-Development-Core' to:
'Seaside-Pharo-Development-Core'"
| oldPackage newPackage oldWorkingCopy newWorkingCopy |
oldPackage := PackageInfo named: oldPackageName.
newPackage := PackageInfo named: newPackageName.
" rename system categories "
oldPackage systemCategories do: [ :oldCategory |
| newCategory |
newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
Smalltalk organization renameCategory: oldCategory toBe: newPackage
systemCategoryPrefix , newCategory ].
" rename method categories "
oldPackage extensionClasses do: [ :extensionClass |
(oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
| newProtocol |
newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
extensionClass organization renameCategory: oldProtocol toBe:
newPackage methodCategoryPrefix , newProtocol ] ].
" update monticello packages "
oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
" test is all methos have been caught "
oldPackage methods isEmpty
ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
unregisterPackage: oldPackage ]
ifFalse: [ self error: 'Some code entities remain in the old
package, please migrate manually.' ]
If you give the prefix 'Fame' then any of the packages 'Fame',
'FameLabs' and 'FameUtil' is picked at random. Previously it only has
worked by chance, as the sorting was implemented slightly different (I
sorted the complete repository, not just the versions in question).
The latest version of Gofer should fix the problem. I added another
hack to the algorithm figuring out the version to load. If there are
exact package matches, the prefix matches are removed. That solves
this problem, and I hope it does not introduce new ones. In any case
you should consider renaming/removing these Fame packages, because
they are not cleanly loadable anyway.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev