Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Pivot to AS renaming

Hi Adolfo

This 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.


        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.


"Pivot" in a method name such as "getPivotResource" can be renamed as

"pivot" as a model element name can be renamed as "ast" and consequently
"get/reset/setPivot" renames as "get/reset/setAst".

I'm not happy renaming "org.eclipse.ocl.examples.pivot" 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 files

".pivot" as a file extension does not look good renamed to ".as",
".oclas" is better and less likely to conflict with other applications

Yes .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? definietely better than qvti.oclas, in my opinion. With content types usage, I guess that xmi file extensions could also "clash".

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 will load 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

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.

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.

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.

Since *.pivot is not usefully saveable/loadable at present I can
probably change to *.oclas while fixing save/load.


I may introduce some synonym classes/methods e.g. getASType() for
MetaModelManager.getPivotType() to ease gradual migration.

It sounds good.

_______________________________________________ mailing list
_______________________________________________ mailing list

No virus found in this message.
Checked by AVG -
Version: 2013.0.3392 / Virus Database: 3211/6611 - Release Date: 08/26/13

Back to the top