Hi
I think it is time for this to move to a Wiki page, since coherence
gets lost in long email threads.
I've created http://wiki.eclipse.org/MDT/OCL/Plugins_and_Features to
capture a possible evolution of feature and plugin names.
I've realized that the Core/Tools names can be misleading, so I've
endeavoured to downplay them.
Names such as +1 and +3 are much clearer since they make it clear
that what is in the +1 build is determined by other projects on the
Simultaneous Release train.
Once promoted, the IA doesn't have to go in the +1 build, since it
is only used by GMF Tooling at +3 'today'. However it can go at +1
and it makes it easier for a +3 project to have fewer +3
dependencies. This is nothing to do with whether IA is Core or a
Tool.
The same rationale makes promotion of the Xtext editors more
interesting. Symmetry suggests that the Pivot model be at +1 with
parsing capabilities. The Xtext parser is at +2. Yet another reason
for having an Xtext-derived LPG parser that can be at +1.
Attached is my summary of possible plugin names. It is certainly
possible to add "tools." to some subcomponents. If it always as
"org.eclipse.ocl.tools.", I'm not that worried, it just seems
redundant. But Adolfo, I think you were adding "tools." in different
places for different purposes. I would expect to add ".tools" to the
IA too, so there would then be a 'tool' in the 'Core' build.
If you print the summary out and start to draw rectangles around
current features, it is clear that we have a ridiculous number of
features for a small part of the project. I've thinned them quite
brutally in the Wiki, but providing an SDK for each subcomponent
ends up with a lot of features again. Perhaps only an overall SDK.
Regards
Ed
On 07/02/2012 11:08, Adolfo Sánchez-Barbudo Herrera wrote:
Hi Ed,
El 06/02/2012 20:05, Ed Willink escribió:
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 should have said "promoted under org.eclipse.ocl.ecore"
namespace, that is, org.eclipse.ocl.ecore.impact*, which was
originally your proposition. However, I misread that you changed
to "org.eclipse.ocl.impact" so, as you said we are not in any
agreement after all ;P
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.
Being fussy, most Java classes could be a tool as well. I'm not
going to go into such a pedantic discussion. To me, as final
Eclipse user I prefer to consider a Tool something I can interact
with, i.e. ui-based stuff. To do a simil, JGit would be the Core,
EGit (which will probably have its core components) would be the
Tool.
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.
Yes they are different, but that's what I want to map. Non-ui
stuff prefixed with core and packaged as Core components, Ui stuff
prefixed with ui, and packaged as UI components.
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.
Indeed, as I originally suggested. On the other hand, I'm fearing
that the "core" (non-ui) part of the current editors (basically
the parsers and evaluators) may depend on Xtext infrastructure,
hence, there would not be any chance to include the new
languages/parsers/evaluators into our Core distribution. So the
mapping I mentioned above is not so clear.
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.
If you still have doubts what Core means to me/how we should
organize components, have a look to the e4 bundles namespace.
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.
As commented, I want to mainly distinguish between core (non-ui)
and ui (let's no mention "tools" if it's more clear) functionality
in the bundles namespace (as e4 does), as long as we want to
package core (non-ui) in the Core distribution and the UI in the
Tools one. The main reasons:
1. Ease the building and packaging for the releng.
2. Clearly distinct the every Core components (probably run in
standalone) and the Ui one (requires the Eclipse UI platform to
run).
If you prefer the EMF approach rather than the e4 one, it's ok to
me, specially if we can't effectively map the core components at
+1 and the ui ones at +3. From the releng point of view, I'm
already managing to package the proper content in the different
distributions, so it's not a problem to me at all.
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.
A 'proof' component would have its core and ui parts, the design
for that component would imply having bundles under o.e.o.core and
o.e.o.tools/ui
Anyways, to resume... I think that all the alternatives are on the
table. As commented, it's OK to me if your final decision is not
separating the core and ui (what I expect for tools) components
via prefixes.
Regards,
Adolfo.
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
_______________________________________________
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/4793 - Release Date:
02/06/12
|
