Skip to main content
aboutsummaryrefslogtreecommitdiffstats
path: root/plugins/uml/decoratormodel/org.eclipse.papyrus.uml.decoratormodel/pom.xml
AgeCommit message (Collapse)AuthorFilesLines
2018-11-27Bug 541594: [UML] [Decorator Model] Remove the generation of the cache ↵Vincent Lorenzo1-5/+7
adapter method in the ProfileExternalization framework Change-Id: I817f00be3123eaf745d37cfa8bc94508f059e411 Signed-off-by: Vincent Lorenzo <vincent.lorenzo@cea.fr>
2018-01-31Bug 529707 Correct the plugin versions in order to avoid clashing dependenciesQuentin Le Menez1-1/+1
Change-Id: Id1e8a4c1d81c9d7ccd04ca6de352e017eba85cab Signed-off-by: Quentin Le Menez <quentin.lemenez@cea.fr>
2018-01-09Bug 515367 - [releng] Uniformization of the end of lines to Unix standardQuentin Le Menez1-10/+10
- Format the EOL of all the files matched by: grep -rIUs . | xargs -Ifile dos2unix -k 'file' Change-Id: I5c41d540a9a67b50de9b912ab35e16cc9a912961 Signed-off-by: Quentin Le Menez <quentin.lemenez@cea.fr>
2016-08-28Bug 443799 - Fix potential bugs identified by FindBugs in oep.infra.*Florian Noyrit1-11/+11
Bug 499554 - Oxygen release version number moved to 3.0.0. Change-Id: I8e112db7175a5b89eb9b37973639627a6c29e007
2016-07-13Bug 496299: Controlled Units as Integral FragmentsChristian W. Damus1-1/+1
https://bugs.eclipse.org/bugs/show_bug.cgi?id=496299 Implement a new mode of controlled unit in Papyrus dubbed "shards". A shard is like any other sub-unit created up to and including the Neon release, except that it cannot be opened independently in the editor. The Papyrus editor, when asked to open a "shard", will instead open the root resource of the model. Likewise, the editor matcher normalizes editor inputs to the root resource of any shard. The graph of shard dependencies is inferred from a new workspace- wide index of cross-resource containment references, when it is available. Otherwise, the linkage of shards to their parent references is parsed on-the-fly from the shard annotation's reference (with a relatively efficient XML parsing that terminates after reading only a few lines of the XMI text). A new ResourceLocator is implemented to provide a pluggable hook for resource loading (including proxy resolution), to ensure when loading a shard resource that its parent resource chain is first loaded from the top down to ensure that all context of profile applications is available before loading the shard, itself, which may have stereotype applications that depend on those profile applications. The CoreMultiDiagramEditor installs this resource locator on the ModelSet; other applications (including in a non-Eclipse context) can make similar use of it. Some additional fixes are required in other core components to make the loading of referenced sharded models as in bug 458837 work: * the SemanticUMLContentProvider did not detect the final resolution of containment proxies that changes what looks look a model root object into just another intermediate element in the content tree. Besides that it would schedule a large number of redundant UI refreshes asynchronously (deferred) on the UI thread * the DiModel and NotationModel would load their adjuncts to the *.uml resource when that resource is created, not after it has been loaded. This is much too early and ends up causing the transactional editing domain to detect the attachment of a resource's contents at the end of loading as an attempt to edit the model during a read-only transaction, which logs an exception and bombs the UI action. Instead, these models now have snippets that load the *.di and *.notation resources after the semantic resource has been loaded. * the new model snippets required an additional fix in the loading of IModels to handle contributions of snippets and dependencies to models that are overridden by other IModels registered under the same ID, such as is the case with the NotationModel and the CSSNotationModel, which latter needs the snippet declared by the former * the IModels additionally need to ensure that they start snippets on loading of an existing model even when it is already found to be loaded in the ModelSet (as happens often in JUnit tests) * the AbstractModelFixture in the JUnit test framework is updated to ensure that the ModelSet is properly initialized, with its own snippets started and its IModels loaded and their snippets started * the basic uncontrol command now removes the shard annotation from the uncontrolled element/resource, if there was one. Because this bundle now supports a new feature (that being shards), it seems appropriate to bump its minor version number General-purpose changes in the core workspace model index framework that improve overall performance, of particular significance in large and highly fragmented models: Implement persistent storage of the workspace model index at workspace save to support quick start-up without parsing the entire workspace. Consolidation of indices: * run a single pool of indexing jobs and a single resource change listener to trigger (re)-indexing of files * all indices matching any given file process it * includes a new extension point from which all indices are loaded into the shared index manager to initialize them and do the work (cherry-picked from streams/2.0-maintenance) Change-Id: Ifd65a71c57134b69d873f17139f3cedbf11c5ba5
2016-02-13Revert "Bug 485220: [Architecture] Provide a more modular architecture ↵Christian W. Damus1-1/+0
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485220" This reverts commit f050d4119a2316b27588076d4fc90152773fc019.
2016-02-13Bug 485220: [Architecture] Provide a more modular architectureChristian W. Damus1-0/+1
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485220 Fix build failure to resolve bundles in referenced p2 repositories by restoring the missing <groupId> elements in the POMs which, as it turns out, are not inherited from the parent module, despite what the m2e validator says. Change-Id: I62dacc9c70c940d28c3c02e1e35c8f874a7d3df0
2016-02-12Bug 485220: [Architecture] Provide a more modular architectureChristian W. Damus1-6/+4
https://bugs.eclipse.org/bugs/show_bug.cgi?id=485220 Factor UI dependencies out of the UML Element Types bundle. This includes moving some advices that interact with the user into a new org.eclipse.papyrus.uml.service.types.ui bundle. Pull up the PasteCommandService and IPasteCommandProvider API into the Infra Diagram layer where the extension point is defined. Deprecate the old API in the UML layer. Introduce a service for participation of languages in CSS styling: * styling reset actions in the Reset Style command * access to semantic model classes and properties to make available to CSS Factor PapyrusObservableValue and cohorts out of the UML Tools bundle into the Infra Layer for more general reuse and to relieve the Diagram Infrastructure layer of UML dependencies. The old API remains as deprecated. Remove the Infra Diagram Layer dependency on UML Layer for property testers governing deletion in the diagram. Includes introduction of a new IGraphicalDeletionHelper OSGi service for delegation of the determination of whether an element can be deleted from the diagram and replacement of the XML expression properties * org.eclipse.papyrus.uml.diagram.common.isSemanticDeletion * org.eclipse.papyrus.uml.diagram.common.isReadOnly by * org.eclipse.papyrus.infra.gmfdiag.common.isSemanticDeletion * org.eclipse.papyrus.infra.gmfdiag.common.canDelete (where the latter is the negation of the property that it supersedes) Extract UML dependencies from the Diagram Outline and CSS Editor bundles. Remove unused MDTUtil APIs that referenced a UML-specific annotation. Move the Diagram Infrastructure CSS Palette bundle into the UML layer because it serves to provide extensions on the Palette Service, which is an overtly UML-specific capability. All client APIs for the Properties View are moved from org.eclipse.papyrus.views.properties bundle to a new org.eclipse.papyrus.infra.properties.ui bundle. This includes renaming of: * extension points * label-provider contexts * XWT namespaces Add an "all UI tests" suite. Define a componentized hierarchical build layout of the main plug-ins Change-Id: I43f8f3644857a18b69715f5a2f1da9b1cf286d67
2015-08-21[releng] Neon-1.2.0 modification step by stepQuentin Le Menez1-2/+2
Change-Id: I9126d707fecad85c9b5384b35074deba995b6527 Signed-off-by: Quentin Le Menez <quentin.lemenez@cea.fr>
2015-06-11469953: [Releng] Update the build to support a global POMCamille Letavernier1-2/+2
https://bugs.eclipse.org/bugs/show_bug.cgi?id=469953 Change-Id: I050cf9dbbdd5705aaf8d45f2db3458226d148002 Signed-off-by: Camille Letavernier <camille.letavernier@cea.fr>
2014-11-06399859: [Profile Applications] Papyrus shall enable to manage profile ↵Christian W. Damus1-0/+14
applications in separate files https://bugs.eclipse.org/bugs/show_bug.cgi?id=399859 Externalize the UI strings in the control-mode plug-in. (+57 squashed commits) Squashed commits: [31a95fd] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Support basic stereotype repair use cases in decorator model resources. ---- [3eaa4ad] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Improve re-application of externalized profiles for migration scenarios, doing away with hacky internalize and re-externalize steps that make a mess of the ordering of stereotype applications in the resource contents. ---- [fa20519] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Complete the copyright updates. ---- [5af536d] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Pluggable profile-application delegate API makes the private AppliedProfilesProvider redundant. ---- [b1e7f68] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Further copyright updates. ---- [ed0788d] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Now that the required UML2 API is available we can remove work-arounds for access to custom profile- and stereotype-application helpers. ---- [b262c2c] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Fix copyright headers. ---- [c4f04a5] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Support for migration of externally applied profiles to a new version. ---- [1892e18] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Additional slightly less trivial test cases for control-mode refactoring. ---- [7e530bd] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Don't create eCrossReferences() lists that compute and cache derived references that don't need refactoring. ---- [a35a57e] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files The undo of control refactoring for unloaded resources needs the same split treatment as for uncontrol. ---- [83249b2] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Automated tests for control-mode participant for refactoring of decorator models. ---- [d4a5149] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Fixes undo/redo of the uncontrolled refactoring for unloaded decorator models, which when undoing would find that the base uncontrol's undo hadn't yet restored the sub-unit resource in which we need to resolve referenced objects. ---- [46f4998] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Fixes to the automatic saving of decorator-model refactoring in (un)control command: - improve the determination of the editor to save (if any) - ensure that we only try to run the save runnable in the workbench window if on the UI thread ---- [1e65796] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Only prompt the user about save requirement if the control action was UI-initiated. Duh. ---- [75ea465] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Initial support for refactoring of currently loaded and unloaded decorator models that apply profiles directly or indirectly to the packages being controlled. ---- [71dfab4] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Fix errors in Javadocs and allow the control command to re-create a resource that the resource set had attempted to load for proxy resolution but failed because it doesn't exist. ---- [45fe94e] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Packages must also inherit externally applied profiles from their nesting package chain. ---- [24428c1] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Refresh the property sheet for the selected package after externalizing profiles to ensure that the "Applications" tab is showing. ---- [4763809] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Replace "Decorator Model" terminology in the UI with simply "Profile Application". ---- [77c00fb] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Remember the user's last auto-prompt load selections for initial selection on next open of the same resource. ---- [651fe70] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Improve JUnit test coverage of core plug-in. ---- [f2d5e7a] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Add an action in the Decorators property tab for packages to duplicate a loaded or unloaded decorator model with support for filtering out certain profile applications. ---- [37eb425] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Fix failure to refresh diagram for CSS styles affected by loading a decorator model the first time (and ensure all subsequent, also). ---- [1d62d00] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Fix problem in refreshing decorator model names in the Decorators property tab. Fix broken "Don't show this again" options in the load-decorator-models wizard. ---- [8ad5bd0] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Option to suppress prompt to unload conflicting decorator models in the Decorator property tab for packages and instead just automatically unload them (supporting quick switch use case). ---- [dde50a3] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Do not confuse users by showing the "decorator models available" icon decoration in Model Explorer on models that are decorated by the decorator model that the user opened in the editor. Only show the icon for referenced ("library") models that are reachable from such models. ---- [a82eb1b] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Improve liveness of action enablement and other tasks (esp. on the UI thread) that depend on the decorator model index. Implement a general-purpose Jobs-based ListenableFuture to support reporting blocked UI tasks in the blocked-jobs dialog. A few more rename refactorings in the API. Improve JUnit test coverage (and fix problems found by new tests). ---- [1cdaa01] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Implement Decorators property tab for packages that have decorator models, to provide easy access to loading and unloading them. ---- [de1cc1c] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Rationalize the handling of empty decorator models by prompting to delete and deleting all Papyrus model member resources in case of deletion. ---- [9bb18ac] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Never prompt to load additional decorator models when opening a decorator model, even if the user model that it decorates has more decorators available and the preference to auto-prompt is enabled. ---- [b1e3315] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Promote the Workspace Model Index and any-root-namespace content type describer APIs to the infra layer. ---- [f708155] 399859: [Decorator Models] Papyrus shall enable to manage profile applications in separate files Ensure responsiveness of label decorators. Apply label decorations to workspace resources in Project Explorer that are decorator models. ---- [4379197] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files WORKAROUNDS for absence of the required new UML API until it becomes available. ---- [68db5f0] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files WORKAROUNDS for absence of the required new UML API until it becomes available. ---- [0bf4163] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Add missing dependency information to top POMs. ---- [04d0935] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Add new plug-ins to top POMs. ---- [d4346cf] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Releng integration. ---- [40cfc0d] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Fix further refresh issues in diagrams when loading decorator models. When existing stereotype applications are loaded, they won't emit SET notifications for the base_Xyz references. Instead, they eventually emit RESOLVE notifications when their base reference proxies are resolved. ---- [f393d19] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Further API refactorings for 'decorator model' terminology. ---- [a3e9dd4] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Only prompt to load decorator models if opening in an editor. ---- [38885bc] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Refactor for 'decorator model' terminology and move the plug-ins into the main source tree. ---- [63c305e] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Various usability enhancements: - label decorators in Model Explorer and applied profiles in package properties indicating source profile externalization model names - prevent conflicts in externalization of profile applications into existing resources - never present profile application resources as available that conflict with native profile applications - revert ModelSet save change that breaks initialization of model from existing UML resource ---- [c1bb42b] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Profile application externalization wizard enhancements: - remember last file extension entered by the user (in case more than just .uml) - let user specify the model name, when creating a new file - verify that when adding to an existing file, it's a profile application model - include the profile application model name in the index ---- [4d1169b] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Enforce uniqueness of profile applications: prevent loading of multiple external profile applications that apply the same profile to the same package. ---- [ac15898] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Require saving dirty profile-application resources before unloading them. ---- [9ad9b0f] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Ensure that PapyrusListeners see changes in profile-application resources as well as the user-model resources. Fix the PapyrusStereotypeListener to handle unloading of a resource containing stereotype applications to interpret the stereotypes as being unapplied. ---- [4c52edd] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Handle problems in (re)building the workspace model index, add a listener protocol, and make it independent of the UML layer. ---- [402c77c] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Add a label decorator (just a placeholder icon for now) for models that have available unloaded profile applications. Add a preference (enabled by default) to prompt to load available profile applications on opening a model, if it has unloaded profile applications available. ---- [8566806] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Add some JUnit tests for the workspace model index framework. ---- [6f500b8] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Ensure that the user models to which a profile-application model contributes profile applications are loaded when the latter is loaded in the Papyrus Editor. ---- [16a0884] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Enable storage of profile applications in UML resources anywhere in the workspace, even in different projects than the models to which they are applied. Uses a new workspace-wide index of cross references between profile-application resources and user model resources, built at start-up and maintained in the background as the workspace changes. ---- [6fe515d] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Hide profile application models in the Model Explorer by default. ---- [69ef817] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Added context-menu actions in the Model Explorer for loading available profile applications that are not yet loaded and for unloading and loaded externalized profile applications (for any currently open controlled units). ---- [d9bb954] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Initial implementation of separate storage of profile applications and their defined stereotype applications in a separate resource. Includes - externalize profile applications refactoring wizard - internalize profile applications refactoring wizard - load profile applications context-menu action in Project Explorer - unload profile applications context-menu action in Model Explorer - enhanced Profile applications table in Properties view for packages ---- [b8578c3] 399859: [Profiles] Papyrus shall enable to manage profile applications in separate files Propagate standard JDT preferences to the sandbox projects. Signed-off-by: Christian W. Damus <give.a.damus@gmail.com> ---- [ec61dd2] 399859: [Profile Applications] Papyrus shall enable to manage profile applications in separate files Update build dependencies to pick up latest UML2 integration build with new APIs required for profile applications feature. Change-Id: Ifa20519ec3209393c88e0a1ac322eac715e541f4

    Back to the top