Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Making OCL.parse() and import directives(Source level incompatibilities in OCL use)
Making OCL.parse() and import directives [message #853436] Sun, 22 April 2012 22:45 Go to next message
Jörn Guy  Süß is currently offline Jörn Guy Süß
Messages: 83
Registered: July 2009
Location: Germany
Member

I am quite happy with the OCLComplete editor for editing ocl source code, but find that OCL.parse() does not accept the IMPORT directives that the editor version requires for its type check and lookup. Is there an easy way to remove these directives or to make OCL.parse() ignore them?

JGS
Re: Making OCL.parse() and import directives [message #853580 is a reply to message #853436] Mon, 23 April 2012 02:24 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4006
Registered: July 2009
Senior Member
Hi

I'm sorry; it's irritating. Now that the pivot-based code for Complete
OCL will not be promoted from examples until after Juno, I've been
thinking about improving compatibility.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=377374 raised).

For now, I recommend putting a distinctive comment after the imports and
read off the file up to the comments before passing the input stream to
the parser.

Regards

Ed Willink


On 23/04/2012 03:45, Jörn Guy Sü Missing name wrote:
> I am quite happy with the OCLComplete editor for editing ocl source
> code, but find that OCL.parse() does not accept the IMPORT directives
> that the editor version requires for its type check and lookup. Is
> there an easy way to remove these directives or to make OCL.parse()
> ignore them?
>
> JGS
Re: Making OCL.parse() and import directives [message #869707 is a reply to message #853580] Thu, 03 May 2012 19:42 Go to previous messageGo to next message
John Guerson is currently offline John Guerson
Messages: 50
Registered: August 2011
Member
Hi,

About this import directive required by the Complete OCL Editor..
import 'platform:/resource/...'

Is there any way of making the editor recognized the model without this explicit declaration? Maybe through some java code, or some property of the Editor ?

Regards,
John
Re: Making OCL.parse() and import directives [message #869733 is a reply to message #869707] Fri, 04 May 2012 01:11 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4006
Registered: July 2009
Senior Member
Hi

Java code: This is the approach required for the Ecore binding. It
doesn't work for the editor.

Editor property: That was the approach taken by the UMLX/QVTd/OCL Model
Registry. Top level package names/aliases could be bound to URIs. The
need for an independent bit of metadata is a nuisance. Where is it? How
does a standalone context find it?

For external referencing, the referencing context must provide a good
portable reference which the tooling can resolve. So for Java the
resolving context has a classpath and the referencing context has a
package hierarchy; the package hierarchy works well, the classpath is a
source of flexibility and many problems. The typical unit of reuse is a
Jar on the classpath.

Models have a reasonable internal package hierarchy, although many
modelers prefer to avoid multiple packages per model. Models are the
unit of reuse and introducing a modelpath on which to find them could be
clumsy. In practice models have nsURIs, even UML Packages now have
nsURIs, so the sensible boundary is for a referencing tool to request a
nsURI and for a resolving tool to have a registry of available nsURIs.
The introduction of the OCL, QVTc, QVTd import statement aligns with
this policy, which was already in place for QVTo (and ATL).

In https://bugs.eclipse.org/bugs/show_bug.cgi?id=377374 you can see that
code has been written and approved to make the Ecore Complete OCL parser
tolerate import statements, so after Juno this irritating
incompatibility should vanish. Other trivial incompatibilities such as
toUpper/toUpperCase have also been eliminated and the new library
functions have been retrofitted to be available in the old context.

Regards

Ed Willink

On 04/05/2012 00:42, John G. wrote:
> Hi,
>
> About this import directive required by the Complete OCL Editor..
> import 'platform:/resource/...'
>
> Is there any way of making the editor recognized the model without
> this explicit declaration? Maybe through some java code, or some
> property of the Editor ?
>
> Regards,
> John
Previous Topic:about the using of OCLinEcore
Next Topic:ocl file parsing
Goto Forum:
  


Current Time: Mon Jul 28 02:19:23 EDT 2014

Powered by FUDForum. Page generated in 0.02244 seconds