Introduction

The current status is that RPackage works well with a one to one mapping package - category.

Done:

• All the events have been migrated from systemNotifier to SystemAnnouncer. The package SystemAnnouncement is ready for inclusion. This means that RPackage does not rely on systemnotifier to keep its data in sync. This also means that SystemAnnouncer can be folded in the system and that other tools can use it. And that we will be able to remove SystemNotifier. Nautilus is only based on SystemNotifier.
• A lot of tests. In addition tests are written in a way that the central RPackageOrganizer is not impacted by test running.
• Nautilus and Moose using RPackage. Nautilus is based on RPackage. Moose uses RPackage as a cache since months.
• Identification of the clients using PackageInfo. We started to identify clients of PackageInfo to prepare migration phase.

Next steps:

• Clean RPackage (because some functionality were copied from PackageInfo):
• Problem Gofer and the some package of RefactoringEngine rely on this API
• Solution: include Refactoring packages in 1.4 and modify it there. In 1.4 we want OCompletion, Ecompletion and Refactoring in the image so this fits well. In subsequent versions we may republish them as separate packages.

• Adding Package Tags. Since people do not want (but have no time to do it - funny isn't) to have one -one mapping between category and package. We will add tags the idea is to be able to have classes sorted inside a package.

    Pack1
         - Tag1 
              ClassA
              ClassB
         - Tag2
              ClassC
              ClassD
              ClassA
     Pack2
        - Tag1
        - Tag3

• MC shoud use RPackage to save information
• Tags should be saved in MC package
• New MC Browser

• should find a solution to this problem. How to get it?

Create a stupid test in the RpackageTest and put a halt. Let the debugger open and recompile a method. {{{packageFromOrganizer: anRPackageOrganizer

self flag: #cyrille. "If the organizer is not able to find the package of a method, it is surely because something went wrong at one point. I got into that situation when having RPackage listening to the system. So a solution I have for now (this is maybe not the best one), is to check if the method is registered in RPackage, and if it is not, simulate a addMethod event to update the organizer. Specific behavior in RPackageOrganizer >> systemMethodRemovedActionFrom: " self methodClass packages detect: [:each | each includesSelector: self selector ofClass: self methodClass ] ifNone: [

|tmpTrait| tmpTrait := (self methodClass traitComposition traitProvidingSelector: self selector). (tmpTrait isNil or: [(tmpTrait packages select: [:aRPackage | (aRPackage includesSelector: self selector ofClass: tmpTrait ) ]) isEmpty ])

ifTrue: [

self flag: 'should not arrive there now'. self halt. self category isNil ifTrue: signal. anRPackageOrganizer systemMethodAddedActionFrom: (AddedEvent

method: self selector: self selector protocol: self category class: self methodClass) asSystemAnnouncement.

].

].

^ anRPackageOrganizer packageDefiningOrExtendingMethod: self}}}