Skip to main content

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

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

Back to the top