Community
Participate
Working Groups
The core purpose is to provide a kind of container where diagrams and services can be plugged. The core is not a repository where to put packages that we don't now where to put :-). A Service should usually be developed in its own plugin. The core dependencies should only be on projects or packages required to provide the core basis. The core should not depends on projects, technologies or packages required by the diagrams or the services themself. Such dependencies should be in the diagram, in the service, or in a common plugin used as basis for this technology. Some (historical) dependencies remains, but will be removed as soon as possible. It is asked to not use this dependencies or add new dependencies. The following action are to be done: - Remove the automatic dependencies export from plugin imported by the core - ex: ecore, swt, sasheditor from sasheditor.di - do not reexport dependencies on - org.eclipse.gmf.runtime.diagram.ui - org.eclipse.emf.edit.ui - Add such dependencies in plugins requiring them - Move in another plugin classes with dependencies on EMF, GMF, ... (example of such classes : /org.eclipse.papyrus.core/src/org/eclipse/papyrus/core/utils/PapyrusEcoreUtils.java /org.eclipse.papyrus.core/src/org/eclipse/papyrus/core/utils/ValidationUtils.java /org.eclipse.papyrus.core/src/org/eclipse/papyrus/core/utils/CrossReferencerUtil.java
Created attachment 184512 [details] mylyn/context/zip Classes and files requiring actions
In r3435: /org.eclipse.papyrus.core/src/org/eclipse/papyrus/core/utils/CrossReferencerUtil.java moved to /org.eclipse.papyrus.diagram.common/src/org/eclipse/papyrus/diagram/common/util/CrossReferencerUtil.java
In need to move the ValidationUtil to a plugin on which all diagrams and the model explorer depend. Thus, diagrams.common is not a good choice (apart from the fact that this plugin is very "big" already). Does someone CC'ed on this bug have an idea into which plugin ValidationUtil should be moved? If not, I propose to create a new plugin org.eclipse.papyrus.util in which we could put things that are commonly used, but neither diagram nor UML specific.
My point of view is that is not a good idea to create a "utils" plugin that will serve as fall down for all classes that we don't know where to put. If such plugin exist, it will grow unexpectedly because we will put everything in it After a while, we will not be able to maintain correctly the plugin. For your "validation" classes, I think that you really should create a "validation" plugin that we can plug or unplug. Furthermore, the modelexplorer plugin should not be aware of such classes: it should just provide the basis enabling plug/unplug of a validation plugin, regardless of the implementation and of the domain technology (here EMF).
Current status: - The core does not depend on GMF - The code depends on GEF (Whereas it shouldn't) - The core editor depends on EMF (And this is required) Only the GEF dependency is still a problem, and it seems it can't be easily removed.
I don't think this is that important, I would even prefer to have GMF runtime (not notation !) in the core to handle all the commands compatibility layer in it. I am ok that we should not depend on diagrams/tables technologies in the core but going further than that is overkill to me.
The current status (From Comment 5) is acceptable I close the task
