|[mdt-ocl.dev] Indication by Adofo that the mature implementation is depecated, Re: mdt-ocl.dev Digest, Vol 46, Issue 4|
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 -> 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 . 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. 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  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.  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
Back to the top