Community
Participate
Working Groups
Papyrus users need to be able to create new models in a repository. The current template-based New Papyrus Model wizard will be enhanced to support pluggable storage providers for new models. The existing workspace file-based new model creation will be refactored as a workspace storage provider on this new extension point, and a CDO storage provider will be added. The wizard will have a new first page that asks the user where to create the new model, according to the available storage providers. In the Kepler release these options will be "In the workspace" and "In a model repository". When the wizard is launched with a workspace resource selection (e.g., in the Project Explorer), then "In the workspace" storage will be selected by default and the wizard will open on the second page. Likewise, when launched with a model repository resource-node selection (e.g, in the Model Repositories view), the "In a model repository" storage will be selected by default and the wizard will open on the second page. When launched without any such selection, the wizard opens on the first page. In the case that only one storage provider is available (which would necessarily be the workspace provider) because the CDO feature is not installed, then the first page of the wizard is never shown.
I'll work on this.
cdo_kepler branch r10206 has the following changes: * refactor the CreateModelWizard class hierarchy for extensibility, to plug in "storage providers" for different kinds of persistence stores in which to create new models * add a new org.eclipse.papyrus.uml.diagram.ui plug-in implementing the CDO Model Repository storage provider A new extension point "newModelStorageProviders" in the org.eclipse.papyrus.uml.diagram.ui plug-in allows to contribute strategies by which the CreateModelWizard presents wizard pages and creates new models. This plug-in provides an own extension for storing new models in the Workspace. The refactoring of the CreateModelWizard class hierarchy extracted out much of the logic of the wizard into the INewModelStorageProvider interface, including: * creating wizard pages for the user to specify where in the persistent store to create the model * reacting to changes in the "diagram category" (modeling language) selection in that wizard page * determining the URI of the principal resource (the *.di) of the new model * creating an appropriate IEditorInput to open the new model in the editor The INewModelStorageProvider also optionally contributes a "part" to the first wizard page (when it is shown) that lets the user select the persistent store in which to create the new model. The CDO implementation provides a list of available repositories for the user to choose from in this page. Some incidental changes were necessary as a consequence of adding CDO storage to the new model wizard, including: * the CreateModelWizard created a local subclass of the DiResourceSet class in order to make the setURIWithoutExtension() method visible. This doesn't work for CDO, which requires the CDOAwareModelSet provided by the ServicesRegistry. So, I reorganized the initialization of the ServicesRegistry in the CreateModelWizard to first initialize the ModelSet, then create the model (which is required by other services!), then initialize the remaining services. The problem of visibility of the protected setURIWithoutExtension() method is addressed by a new "Internal" adapter interface provided by any ModelSet * the CreateModelWizard overrides the Wizard APIs for page management, because all available INewModelStorageProviders contribute pages to it but only one set of these is "active" at any time. So, computing the next/previous page and surveying pages for "isComplete" state accounts for this Currently, it appears that the wizards that create multiple models at once (in a new project or not) are not used; they are dead code. Thus, I attempted to update them correctly in this refactoring but did not test them. Regression testing shows that the creation of new models (including SysML and Profile models) and new projects in the workspace seems to be OK. Ad hoc testing of creating new models in a CDO repository also seems to be OK.
cdo_kepler branch r10221 adds support for initializing a Papyrus model (diagrams) from an existing domain model, in a CDO repository. This entails a minor refactoring of the SelectRootElementPage to initialize it with the original IStructuredSelection from the workbench instead of an IFile, as in the CDO case the selection is a Resource that is already loaded in some view. That means that in the CDO case it is not necessary for this page to create a ModelSet to load the selected resource, because it would be difficult to create the correct ModelSet implementation (it would mean creating and tearing down a ServicesRegistry, but it mustn't be torn down until the wizard has finished, because the resource would become invalid as soon as the view is closed). It also requires that the Model Repositories view show "unaffiliated" resources, those that are not components of DI models, so that the user can select them to initialize the model. SO, this is now donw.
r10380 This enhancement has been merged to the trunk.
