Hi Ed,
Today is quite easy to identify OCL Tools components, that is:
org.eclipse.ocl.examples.*
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[1] -> 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 [2].
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: [1] Just to name the impact analyzer. This obviously could be
organized as Axel requires/expects.
Note: [2] I know that I'm missing a lot of plugins, but I hope the
idea is caught.
Best Regards,
Adolfo.
El 03/02/2012 14:18, Ed Willink escribió:
Hi Adolfo
Would you like to put together a proposal for revised feature and
plugin names and hierarchy, since your releng perspective gives
you slightly different interests? 4.0.0 is a major version so we
can totally reorganize if absolutely necessary - I hope not.
From a modeling perspective, a Feature contain Features or Plugins
so a simple indented list is sufficient to identify the intended
location of all plugins and features and Update Site Names.
feature X (Descriptive Name for X)
plugin Y
feature Z (Descriptive Name for Z)
plugin A
For the sake of future proofing, assign names as if all plugins
are promoted from examples now; we'll just defer renaming examples
plugins until they are actually promoted.
Regards
Ed
On 03/02/2012 13:58, Adolfo Sánchez-Barbudo Herrera wrote:
Finally, I would like to remark (I've not thought about it) the
importance of the new namespace from the point of view of
another stakeholder: The releng :). It could be interesting to
avoid problems like [1] or further changes in the releng stuff
configuration to accomodate new plugins, having a "coherent" or
"uniform" namespace to distinguish Core components from the
Tools one.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=370347#c1
El 03/02/2012 12:03, Ed Willink escribió:
plugin and other global names
These obviously change. The simplest change is just delete
".examples". Do we want to do something else?
It would be nice if the event plugins went to EMF, but that
doesn't look likely, so they too need review.
It would be nice to have names that can accommodate the pivot
model sometime. I would like to try to partition the code into
the run-time code that performs (re-)evaluation and the
meta-run-time code that maintains the control objects that
make IA so good. If this is possible, then we want
corresponding names. Perhaps
org.eclipse.ocl.ecore.impact.runtime
org.eclipse.ocl.ecore.impact.analyzer
I hope that migration of the run-time code to align with the
code generated Java can be done quite easily, since the code
generated Java makes no use of any form of the OCL meta-model;
just the polymorphic Values and polymorphic Domain model for
which there is direct and Reflective Ecore support. Perhaps
org.eclipse.ocl.domain.impact.runtime
Migration of the meta-run-time code will be harder because
that obviously makes use of the OCL meta-model. Perhaps
org.eclipse.ocl.pivot.impact.analyzer
In order to avoid code duplication, code that is independent
of Ecore/UML/Pivot should be in perhaps
org.eclipse.ocl.common.impact
It may also be appropriate to place some declarations
independent of Ecore/UML/Pivot such as extension points in
org.eclipse.ocl.common
We cannot easily use org.eclipse.ocl since that is highly
Ecore/UML dependent.
NB being independent of Ecore does not prohibit use of
EObject, EObject.eClass() etc. I hope that the external API
facade can be Ecore/UML/Pivot independent and so in
org.eclipse.ocl.common.impact.
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|