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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev