Utility classes for EMF.Edit not independent of RAM

[Matthias Schoettle]

Several utility classes for working with EMF.Edit, such as ca.mcgill.sel.ram.controller.edit.AdapterFactoryRegistry and ca.mcgill.sel.ram.controller.edit.AdapterFactoryUtil and even parts of ca.mcgill.cs.sel.ram.provider.util.RamEcoreUtil use RAM-specific classes and hence make it dependent on RAM.

However, this dependency is unnecessary. Currently it is not possible to reuse these classes for different metamodels (e.g., CORE). This also applies to ca.mcgill.cs.sel.ram.util.RAMPersistence, which could be made general to be able to load and save a model of any metamodel.

I suggest to move these classes (or the methods that are only EMF-specific) to the commons project introduced in issue #82.

[Matthias Schoettle]

References issue #83: Moved EMF utility classes to commons project and made them independent of a specific metamodel (like RAM).

ResourceManager: Helper methods used to work with resources (load and save models).

AdapterFactoryRegistry: Registry to keep adapter factories for models.

EMFEditUtil: Convenient helper methods to work with EMF.Edit related tasks for any metamodel.

EMFModelUtil: Convenient helper methods to work with EMF Model related tasks for any metamodel.

EditingDomainProvidingComposedAdapterFactory: ComposedAdapterFactory that knows the editing domain.

→ <<cset 4047d5b2b47c>>

[Matthias Schoettle]

References issue #83: Deleted RAMPersistence (no longer required).

→ <<cset 878a1217a2b9>>

[Matthias Schoettle]

References issue #83: Removed complete .edit package (no longer required). Changed RamEcoreUtil usage to new EMFModelUtil. Changed AdapterFactoryUtil usage to new EMFEditUtil.

Addressed checkstyle problems at the same time.

→ <<cset 8801a0b58163>>

[Matthias Schoettle]

References issue #83: Moved usage of EMF model and edit operations to new corresponding util classes in commons.

→ <<cset 0cfd4e30f5a6>>

[Matthias Schoettle]

References issue #83 and #67: Renamed RamEcoreUtil to RAMEditUtil.

→ <<cset 89af3aa7435d>>

[Matthias Schoettle]

References issue #83 and #67: Removed methods that were moved to EMFModelUtil and EMFEditUtil.

→ <<cset 230ffa047044>>

[Matthias Schoettle]

Resolved issue #83: Finished. Removed usage of old classes that were moved to commons project and renamed.

→ <<cset f502e7b929e9>>

[Matthias Schoettle]

References #83: Fixed problem where EMFEditUtil failed to load the proper string resource in the generated editor. The item provider factory for RAM was registered for the wrong namespace URI.

→ <<cset 8da6f7a7dbb2>>

[Matthias Schoettle]

Changes broke updating the command stack (e.g., when changing something in a TextView):

Always the same AdapterFactory and its CommandStack is used to execute commands. For example, when loading Observer also ZeroToMany is loaded (and an AdapterFactory created for each). When changing something in Observer the AdapterFactory of ZeroToMany is used instead of the one for Observer.

[Matthias Schoettle]

Resolved issue #83 again: Instead of adding a new instance of each adapter factory, only one adapter factory was used, which was used for every item provider.

Now, instead of adding an instance of an adapter factory to the registry, the class is added and when initializing a new adapter factory and editing domain, instances of these adapter factories are created.

→ <<cset 5c4a561847b5>>