| Making OCL.parse() and import directives [message #853436] |
Mon, 23 April 2012 02:45  |
|
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 #869733 is a reply to message #869707] |
Fri, 04 May 2012 05:11  |
 Ed Willink
Messages: 7655
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
|
|
|
Powered by
FUDForum. Page generated in 0.03871 seconds
] 
Search
Help
Register
Login
Home
