Community
Participate
Working Groups
Past releases of Papyrus provided a Documentation view that implements attachment of external documents (PDF, Word, images, whatever formats) from the local workspace or the Web to model elements. CDO adds to this the possibility of referencing documents stored as binary resources (BLOBs) and text resources (CLOBs) in the repository. This should be added as an option in the Documentation view's support for external document links. It is not necessary for Papyrus to provide a user interface for storing and managing such documents in the repository; the CDO UI already provides this. What Papyrus must implement is the management of the association of model elements with these documents.
Hmm, we have a problem. The org.eclipse.papyrus.uml.documentation plug-in provides a UML-specific documentation manager that attaches documentation to model elements via owned comments with the «documentation» stereotype applied. The problem is that this plug-in registers its documentation manager only against old UML namespaces, up to version 3.0.0, not the 4.0.0 namespace that shipped with the Kepler release. Consequently, the default annotation-based scheme for attaching documentation and resources is used by the Kepler release of Papyrus and, so far, Luna. Fixing this by registering UMLDocumentationManager on the latest UML namespace in the Luna release (or a Kepler SR) would cause immediate data loss upon software update, as existing models would start ignoring all of the data in the annotations. AFAICS, there is no provision for migrating data from one documentation manager to another, and I haven't the budget to address that. However, I'm not sure whether this is worse than the data loss already suffered by any users that upgraded to the Kepler release, because that migrated their UML models from the 3.0.0 namespace to 4.0.0. This then caused Papyrus Kepler to ignore all of the documentation information stored in the «documentation» comments because it is looking for the annotations. Fixing the manager registration would actually *restore* that information. I solicit comments to help decide the best course of action: * continue without the UML-specific documentation manager for Luna and subsequent releases (the oep.uml.documentation* plug-ins then should be removed from the build) * add the registration of the UMLDocumentationManager for the 4.0.0 namespace and hope that the recovery of documentation data lost in Kepler outweighs the loss of documentation data in Luna
I've forked the comment #1 as a new bug 417455.
It appears from off-line discussion that the Documentation View is, in fact, obsolete. Therefore, this enhancement is being re-targeted to the generic hyperlinking facility provided by Papyrus in the diagram editors.
I have pushed a new branch bugs/415373 with a proposed implementation of this enhancement. Of particular interest, for which I would appreciate review by the team (Camille?), are some changes in the main-line Papyrus plug-ins, as described below. ## Consolidate hyperlink helpers into one tab In the Hyperlink editor dialog in the Kepler release, every different kind of hyperlink contributed by helpers was in its own tab. However, all of these hyperlinks are presented and manipulated by the user in the same way; separating them into tabs doesn't scale (especially when I need to add another kind of hyperlink for documents in CDO repositories!). To this end, I updated the HyperLinkTab and HyperLinkTabsRegistrationUtil to add all contributed helpers to a single tab via a composite helper. The + button shows a pop-up menu of hyperlink types to add. See commit 2ccec6839007aea0d7a072fb39b6485c4a5bfcf4 for details. ## New Object Localizer service To support drag-and-drop from the Model Repositories view to the diagrams to create hyperlinks, the EObjects being dragged need to be "localized" to the resource set in which the drop occurs. The Kepler release of DropTargetListener already did this in the obvious way, by getting the corresponding EObjects in the local resource set by URI. However, this doesn't work for EObjects that are CDO resource nodes in the Model Repositories view: CDOResourceNodes are contained by a resource that doesn't behave like normal resources, and a different strategy is needed to "localize" them in the receiving resource set. To that end, I have added a new plug-in oep.infa.services.localizer that defines an IObjectLocalizer service to abstract this behaviour. The default implementation of the service is as before in Kepler and the DropTargetListener now delegates to it. The CDO integration layer overrides the default service with one that is aware of the CDO-isms. See commit 62819fbb7ac0880825cd0770593441f351302033 for details. ## HyperlinkDropStrategy delegation to helpers Finally, with all of the groundwork above in place, I modified the HyperlinkDropStrategy that in Kepler knew only how to create hyperlinks for dropped diagrams to delegate instead to the contributed hyperlink helpers. This relies on a new interface IHyperlinkHelperExtension that is optionally implemented by helpers to provide a Command that creates a hyperlink from some object. The drop strategy delegates to the helpers that implement this interface to create the drop command; its former implementation of diagram-editor dropping is moved to the EditorHyperLinkHelper class. See commit 1d0196dd4cfa35f2ed1606ee717f4f5766bb8b61 for details.
Hi, Camille, Could you please review my changes to the main-line plugins as detailed in comment #4 on the bugs/415373 branch, or delegate to somebody else on the team? I would like to push this to master for M2. Thanks! Christian
This looks good (And much better from a Usability point of view! :) ) I just have a compilation error on the dependency version from a CDO plug-in to the Localizer service (10.0.1 / 10.0.100?).
(In reply to Camille Letavernier from comment #6) > This looks good (And much better from a Usability point of view! :) ) Thanks very much for taking the time to review this, Camille! I appreciate it. > I just have a compilation error on the dependency version from a CDO plug-in > to the Localizer service (10.0.1 / 10.0.100?). Oops, I think probably I missed something when I pushed that branch. I ended up going with the same old 0.10.1 version so as not to confuse matters when you do the update to 1.0.0. I'll make sure that doesn't happen on master. :-)
Fixed in commits 3e3718da1abeb84f0b0140b21fb2cfce7fa2ee11 through c00ac21e3e3d1a509613f990db4f2c0c058d4efb Hyperlinks to documents (file resources and models) in CDO model repositories are supported in the hyperlinks dialog and by drag-and-drop onto the diagrams.
(updating target milestone to reflect delivery in M2)
