|Re: [mdt-ocl.dev] Pivot to AS renaming|
Hi AdolfoThis renaming is very dangerous, since although the 'examples' plugins are not frozen API, we have increasing numbers of users.
In sorting out the pivot save/load I introduced a new pivot.resource package to reduce the number of classes jumbled in pivot.utilities. Unfortunately this moved BaseResource and broke Papyrus; Papyrus worked fine but any attempt to edit an OCL expression gave an error log line rather than a popup editor. So I've reverted that specific rename and Papyrus is ok.
However we certainly have newsgroup participants being more enthusiastic about the Java API and so I suspect that the as2pivot to as2cs renaming breaks some of them. I'm inclined to revert all these renames and save them up for a major rationalization just before removing the 'examples' from plugin names etc.
Significant name changes must be done with deprecation, cf TypeManager for MetaModelManager.
Regards Ed Willink On 27/08/2013 09:52, Adolfo Sanchez-Barbudo Herrera wrote:
On 21/08/2013 10:55, Ed Willink wrote:Hi Adolfo In principle we agreed that we should rename Pivot to AS but it's not that simple. For my recent CSE commit of the codegen plugin I converted about 800 "Pivot"s to "AS" leaving about 200, mostly in import paths, or PivotUtil of API methods.Ok."Pivot" in a method name such as "getPivotResource" can be renamed as "getASResource" "pivot" as a model element name can be renamed as "ast" and consequently "get/reset/setPivot" renames as "get/reset/setAst".Nice.I'm not happy renaming "org.eclipse.ocl.examples.pivot" as "org.eclipse.ocl.as". Perhaps we should use "org.eclipse.ocl.oclas" which helps later.I think that maintaining .pivot as the plugin name should be fine / not hurt nobody.======================================== "pivot" as a URI protocol/scheme seems to have been an aberation that is going away as I fix loading/saving of pivot filesOk.".pivot" as a file extension does not look good renamed to ".as", ".oclas" is better and less likely to conflict with other applicationsYes .oclas looks good.A QVTi CS text file: "*.qvti" A QVTi CS XMI file: "*.qvti.xmi" A QVTi AS XMI file: "*.qvti.oclas"I guess that a QVTiAS as XMI file, should similarly use qvtias? qvti.as definietely better than qvti.oclas, in my opinion. With content types usage, I guess that xmi file extensions could also "clash".I think that I understand the oclas file extension. This sounds tricky and I've not struggled enough with pivot metamodel usage to see the motivation/need right now.We need the double extension on the AS so that a reference to Ecore.ecore.oclas creates a Pivot Resource that loads Ecore.ecore and performs the Ecore2Pivot conversion. Similarly a reference such as http://www.eclipse.org/emf/2002/Ecore.oclas#//EJavaObject will load http://www.eclipse.org/emf/2002/Ecore and convert. (This was the original idea behind a "pivot:" scheme, but a ".oclas" extension is simpler and does not need any name mangling to convert to pivot://http/www.eclipse.org/emf/2002/Ecore.This what I suggested before :P. I see some benefits of using specific file extensions, but to be honest I don't like things like oclas, oclcs, or what ever.The extension doesn't have to be ".oclas", but trying to use ".xmi" for the AS (and something else for CS) will give all sorts of obscure conflicts with other applications that do not consistently register *.xmi for content-type only resolution.Since *.pivot is not usefully saveable/loadable at present I can probably change to *.oclas while fixing save/load.OkI may introduce some synonym classes/methods e.g. getASType() for MetaModelManager.getPivotType() to ease gradual migration.It sounds good.Regards Ed _______________________________________________ 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: 2013.0.3392 / Virus Database: 3211/6611 - Release Date: 08/26/13
Back to the top