|Re: [mdt-ocl.dev] Evolving plugin/feature names|
Today is quite easy to identify OCL Tools components, that is:
The problems come when identifying Core components, unless we consider Core everything is not o.e.o.examples.* (However, this doesn't help from the point of view of the regular expressions which are used, anyway).
From a releng (and any user) perspective it would be quite easy identify components if we had:
- org.eclipse.ocl.core.* for Core components.
- org.eclipse.ocl.tools.* for Tools components.
This distinction could help, if we desired to have documentation, examples and tests for both Core and Tools components:
- org.eclipse.ocl.core.doc for Core API usage documentation/help.
- org.eclipse.ocl.core.examples.* for Core API usage examples.
- org.eclipse.ocl.core.tests.* for Core API tests.
- org.eclipse.ocl.tools.doc for Tools documentation/help.
- org.eclipse.ocl.tools.examples.* for Tools examples.
- org.eclipse.ocl.tools.tests.* for (probably UI-based) tests.
This namespace could also help to identify the future components of the project. Everything not scoped in org.eclipse.ocl.core/tools should probably be deprecated and eventually deleted in future releases. I imagine something like the following:
org.eclipse.ocl -> mature, deprecated code
org.eclipse.ocl.uml -> mature, deprecated code
org.eclipse.ocl.ecore -> mature, deprecated code
org.eclipse.ocl.ecore.impactanalysis -> impact analysis for the mature deprecated code
org.eclipse.ocl.core.pivot -> new pivot implementation
org.eclipse.ocl.core.essentialocl -> new pivot-based Essential OCL Implementation
org.eclipse.ocl.core.completeocl -> new pivot-based Complete OCL Implementation
org.eclipse.ocl.core.impactanalysis -> impact analysis for the new pivot-based implementation
org.eclipse.ocl.core.doc -> documentation for the Core API usage
org.eclipse.ocl.core.examples.* -> Examples for Core API usage.
org.eclipse.ocl.core.tests.* -> tests for Core API.
org.eclipse.ocl.tools.console -> OCL Console.
org.eclipse.ocl.tools.editor.essentialocl -> Editor for Essential OCL
org.eclipse.ocl.tools.editor.completeocl -> Editor for Complete OCL
org.eclipse.ocl.tools.doc -> documentation/help for Tools.
org.eclipse.ocl.tools.examples.* -> examples for Tools.
org.eclipse.ocl.tools.tests.* -> (probably UI-based) tests for Tools.
... and such .
Again, this is a suggestion, which could make sense since we are now distinguising and exposing different Core and Tools components. It's not a necessity at all.
Adding a new/good features organization, we could finally distribute Core components in a pure Core Repository, and the Tools components in a pure Tools Repository. We could also distribute the current (deprecated and removed in the future) Core components in a "Deprecated Repository".
Nowadays, because of the current feature organization, the Core Repository contains only Core Components, however, the Tools repository contains both Core and Tools components.
Note:  Just to name the impact analyzer. This obviously could be organized as Axel requires/expects.
Note:  I know that I'm missing a lot of plugins, but I hope the idea is caught.
El 03/02/2012 14:18, Ed Willink escribió:
Back to the top