[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] Indication by Adofo that the mature implementation is depecated, Re: mdt-ocl.dev Digest, Vol 46, Issue 4
|
Hi Philipp
There a massive difference between 'mature' and 'deprecated'. I'm afraid
that you are reading much too much into a planning document which is
looking at the position we are trying to get to, not where we are today.
The existing legacy plugins are mature, but they are certainly not
deprecated
a) because there is no non-examples replacement
b) because I am not actively encouraging migration of Java API users
The new examples functionality provides functionality that adds value as
well as alternatives.
The OCLinEcore supports development of embedded OCL, that happens to use
the new code while editing, and the old code when the embedded OCL is
executed interactively.
The new code generator takes this further by generating direct Java that
doesn't use either new or old OCL; just an OCL VM.
In both cases the user is largely unaware whether old or new code is in
use. So for the modeler the transition is comparatively smooth and good
news. It is for the Java API user that we need to work hard to ease the
transition. I'm hoping to work with Acceleo and QVTo after Juno to
achieve this for Kepler.
The existing legacy plugins will certainly not be deprecated before
Kepler, and I would expect at least of couple of years before they are
withdrawn, if at all.
Regards
Ed Willink
On 04/02/2012 10:21, Philipp W. Kutter | Montages AG wrote:
Hi. Adolfo.
Date: Fri, 03 Feb 2012 16:15:17 +0000
From: Adolfo S?nchez-Barbudo Herrera <adolfosbh@xxxxxxxxxxxxxxxx>
To: mdt-ocl.dev@xxxxxxxxxxx
Subject: Re: [mdt-ocl.dev] Evolving plugin/feature names
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
How can we propose something mature as deprecated if
- many other projects relay on it
- the replacement is neither completely finished, nor its completion
if fully funded?
I think, by such a move we are simply helping those who want to
replace the OCL based frameworks with non-standard based ones.
I am not at all against the Pivot work done, and I see its merits. As
well, I am looking forward to the new compilation components.
However, as Ed Willink noted many times, there are risks and there is
a status of underfunding.
I do not think that we solve these problems by declaring our mature
implementation - which is used in products such as RSA or RSM (AFAIK)
and reused by Eclipse frameworks like QVTO and GMF Tooling, and used
acttively in companies such as SAP - as deprecated.
I would strongly wish to hear another message from the OCL team,
especiallly in protecting their investments and hard work.
Please let me know, if I can be of any help.
Ed Willink: I think as a component lead you have to give out a strong
message: either the mature bindings (one or both) are still supported,
or they are deprecated. There is now gray in this.
Regards, Philipp
On 03.02.2012 17:15, mdt-ocl.dev-request@xxxxxxxxxxx wrote:
S
------------------------------
Message: 2
Date: Fri, 03 Feb 2012 16:15:17 +0000
From: Adolfo S?nchez-Barbudo Herrera <adolfosbh@xxxxxxxxxxxxxxxx>
To: mdt-ocl.dev@xxxxxxxxxxx
Subject: Re: [mdt-ocl.dev] Evolving plugin/feature names
Message-ID:<4F2C0815.4000506@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hi Ed,
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/4786 - Release Date: 02/03/12
