Thanks, it's much easier to move forward once you have a stake in
Uniform core/tools prefixes seems attractive but, to avoid confusion
from existing facilities, consider what would happen if we added a
new symbolic proof tool.
With uniform core/tools prefixes we might have:
whereas if we group by tool rather than delivery we might have
If we need to use examples as an incubation area, during the
examples phase we have no problem with
But if we find we need three categories of build rather than two,
using the build category as a package prefix is unhelpful.
Also, I'm not sure that users want to have core/tools as part of
their imported package path.
For tools at least I think we need a clear tool name as the first
name. Subsequent names we can try to make regular to so that
*.doc.*, *.tests.*, *.examples.*, *.runtime.* makes releng
partitioning fairly easy.
For the current plugins "ecore" and "uml" can be regarded as tool
names, so "ecore.tests" and "uml.tests" are regular names.
For the Impact Analyzer then "impact" is short and snappy, so
perhaps we want "impact.ecore.runtime", "impact.ecore.analyzer",
"impact.common.analyzer", "impact.tests", "impact.examples",
For the Console, I would look towards
http://wiki.eclipse.org/MDT/OCL/Debugger and so we might be looking
at "debugger.input", "debugger.variables", "debugger.breakpoints",
... once we eventually promote from examples.
For the Xtext editors, "editor..." is probably ok, unless we want to
split as "parser" and "editor". We can decide this later.
The Pivot model seem the hardest bit, because there is the neutral
domain model. Perhaps "vm.runtime", "vm.model", "vm.library" so that
"pivot" is left with a fairly similar purpose to "ecore" and "uml".
So we have the following top level 'tools':
common (may not reference any other 'tool')
and the only plugins that do not comply are org.eclipse.ocl and
Tool-specific facilities are in ...tests..., ...examples...,
...doc.... Cross-tool integration is in tests..., examples...,
The above is for plugin/package names.
I think Core/Tool prefixes would be good for feature names since if
we need to have three deliveries we probably need to re-arrange
On 03/02/2012 16:15, Adolfo Sánchez-Barbudo Herrera wrote:
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
mature, deprecated code
org.eclipse.ocl.uml -> mature,
org.eclipse.ocl.ecore -> mature,
org.eclipse.ocl.ecore.impactanalysis -> impact analysis for
the mature deprecated code
org.eclipse.ocl.core.pivot -> new
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
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
org.eclipse.ocl.tools.editor.essentialocl -> Editor for
org.eclipse.ocl.tools.editor.completeocl -> Editor for
documentation/help for Tools.
org.eclipse.ocl.tools.examples.* -> examples for
(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ó:
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
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
feature X (Descriptive Name for X)
feature Z (Descriptive Name for Z)
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.
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  or further changes in the releng stuff
configuration to accomodate new plugins, having a "coherent"
or "uniform" namespace to distinguish Core components from the
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
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
Migration of the meta-run-time code will be harder because
that obviously makes use of the OCL meta-model. Perhaps
In order to avoid code duplication, code that is independent
of Ecore/UML/Pivot should be in perhaps
It may also be appropriate to place some declarations
independent of Ecore/UML/Pivot such as extension points in
We cannot easily use org.eclipse.ocl since that is highly
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
mdt-ocl.dev mailing list
mdt-ocl.dev mailing list
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4781 - Release Date: