Hi Adolfo
At least we have got an agreement, the current impact analyzer
should be promoted to org.eclipse.ocl.ecore :)
I do not know what you mean, so I cannot be in agreement.
I don't see the Impact Analyzer as part of the org.eclipse.ocl.ecore
plugin; we must not add so much code to existing functionality.
I don't see the Impact Analyzer as part of the org.eclipse.ocl.ecore
feature; we must not add so much code to existing functionality.
I do see the Impact Analyzer as part of the Core build.
I see promotion as dependent on a satisfactory review, so I do not
yet agree that the current Impact Analyzer should be promoted.
I also see promotion as dependent on a decision on namespace issues.
I've always seen the OCL Tools components as those UI-based
components which rely on a OCL Core infrastructure, as they were
thought and we had been developed in the currently terminated OCL
Tools project. Whereas the OCL Core components could sensibly work
in stand-alone mode, the Tools components could probably need some
Eclipse UI platform to run. Remember the namespace used to
distinct bundles between the "MDT/UML" project and the "MDT/UML
Tools" one.
The MDT/UML2 split is easy; the UML project supports just models in
UML, CMOF and Ecore forms. Everything else is a tool.
MDT/OCL already has some tools as core; the parser, analyzer and
evaluator are 'tools'. The Impact Analyzer is a tool.
I see a Tool as a coherent module of additional functionality, which
may or may not have a UI. The Impact Analyzer just happens to have
no UI at present. I suspect that some profiling might support
interactive optimisation.
On the one hand, distinguishing Tools components with a prefix
does quite sense to me. Looking at a Juno installation, excepting
the "org.eclipse.e4.emf.xpath" bundle, every bundle of the "new"
e4 project are categorized in a "core" / "ui" fashion. On the
other hand, projects like EMF have its UI components categorized
in the respective feature as you suggests.
In my hypothetical 'proof' tool I tried to address this. UI/not-UI
is a different issue to Core/Tools. All the xtext editors come as
two plugins; a non-UI and a UI one. So every Xtext editor splits
across your Core/Tools boundary.
I prefer the "core/tools" prefixes since it clearly distinguish
core from UI-based components, apart from the benefits I mentioned
in my previous post. Perhaps "ui" sounds better for you. Perhaps
we could not introduce the "core" prefix, but at least use
"tools/ui" one.
(I don't like '.ui' but anything else would now be worse.)
Note that EMF uses suffixes: ".edit", ".editor", ".impl" not
prefixes.
What is your definition of 'Core'? I suspect it is what is packaged
in the Core build. Packaging can change, tools change much less, so
I don't like naming tools according to today's packaging policy.
Whether EMF's ".edit", ".editor" are in separate plugins is a
packaging decision that can be changed without renaming.
Perhaps a useful analogy is with emf and m2m and mdt. Projects
started with a prefix org.eclipse.emf.ocl,
org.eclipse.m2m.qvt.declarative and then lost it; org.eclipse.ocl.
org.eclipse.qvtd... A few well-chosen names keep things orthogonal.
It would be very confusing to have different emf.mtf, m2m.mtf,
mdt.mtf projects so the prefix is not needed. Projects can be
regrouped without renaming. emf and m2m and mdt are selectively
redundant packaging names.
With my suggestion all Impact Analyzer contributions start
org.eclipse.ocl.impact; you're adding a ".tools" and maybe more.
Finally I would like to better understand the/understand more
inconvenients of my proposal. Your first argument doesn't suffice
to me: we would be suffering of the same issue if we had had to
deal with a separate OCL Tools project, and the Eclipse "Working
Sets" help to organize the bundles in the workspace (for instance
to group bundles concerning the same feature/tool, regardless its
namespace).
If we added a 'proof' component to a separate Tools project we would
not be able to modify the Core project, so if the 'proof' component
has a run-time, we would have to create Tools-runtime and Tools-ui
features to separate them. Users would need to access one or two of
Core/Tool-runtime/Tools-ui. With the merged project, users just
choose one of Core/Tools.
If we had a separate independent OCL Tools project we might be
promoting o.e.o.tools.examples.impact* to o.e.o.tools.impact*.
If we had a separate collaborative OCL Tools project we might be
promoting o.e.o.examples.impact* to o.e.o.impact* which is just what
we have with an integrated Tools project.
Regards,
Ed
Adolfo.
El 04/02/2012 11:59, Ed Willink escribió:
Hi Adolfo
Thanks, it's much easier to move forward once you have a stake
in the ground.
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:
core.proof
core.doc.proof
core.examples.proof
core.tests.proof
tools.proof.compiler
tools.proof.editor
tools.doc.proof.editor
tools.examples.proof.editor
tools.tests.proof.editor
whereas if we group by tool rather than delivery we might have
proof.runtime
proof.compiler
proof.editor
proof.examples
proof.tests
proof.doc
If we need to use examples as an incubation area, during the
examples phase we have no problem with
examples.proof.*
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",
"impact.doc"
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')
ecore
uml
pivot
vm
impact
parser
editor
debugger
codegen
and the only plugins that do not comply are org.eclipse.ocl and
org.eclipse.ocl.tests
Tool-specific facilities are in ...tests..., ...examples...,
...doc.... Cross-tool integration is in tests..., examples...,
doc...
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 features anyway.
Regards
Ed
On 03/02/2012 16:15, Adolfo Sánchez-Barbudo Herrera wrote:
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4781 - Release
Date: 02/02/12
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4792 - Release Date:
02/06/12
|
