Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] multiple instances of oclstdlib 
Hi Andrew,
Are you using the generated Acceleo launcher in order to launch your generation? We register the OCL standard library's package in the resource set used to load the model before doing anything else, so re-registering it, especially in the global registry, shouldn't make any difference if you were.
The least I can tell you is that you should avoid registering the stdlib within the global registry (EPackage.Registry.INSTANCE) but register it in the resourceSet you use instead (resourceSet.getPackageRegistry()). Acceleo does that from the generated launcher's (sub-class of AbstractAcceleoGenerator created beside your "main" mtl file) "registerPackages()" method. 

Laurent Goubet
Obeo

On 10/04/2014 21:34, Andrew Eidsness wrote:

I see.  If it is only a problem in the runtime workspace, then I can deal with the issues.  I had assumed that it would
also affect the binary install, but it is good to know that doesn't seem to be the case.

BTW: I had the same problem when the ocl.ecore plugin was pulled in from my Target Platform (when I closed the project
in my workspace).

As for addressing the problem, I've found that registering the OCL Standard Library in the global EPackage.Registry
during my plugin's activation fixes things (in my runtime workbench).  Does this sound like a bad idea?  To be clear,
this is what I put into my Plugin's #start(BundleContext) method:

	EPackage.Registry.INSTANCE.put(
		EcoreEnvironment.OCL_STANDARD_LIBRARY_NS_URI,
		new EcoreOCLStandardLibrary().getOCLStdLibPackage());

This way, when my .emtl files are executed (from this plugin) they load the OCL's common shared library package.  It
fixes the problem in my runtime workbench.  The reason I'm asking here is that the bug you pointed at lists 5 or 6
different URI formats, and I don't really understand whether this will deal with the variants, or if I'm just getting
lucky in my runtime session.

-Andrew

On 14-04-10 12:03 PM, Ed Willink wrote:

Hi Andrew

I'm sorry. In Acceleo, all bets are off. The URI resolution is severely broken. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360926#c8.

One tip; on no account have org.eclipse.ocl.ecore open in your workspace.

The unpredictability of Acceleo was eventually a driver for migrating all primary Eclipse OCL M2T templates from Acceleo
to Xtend.

     Regards

         Ed Willink


On 10/04/2014 16:41, Andrew Eidsness wrote:

I’m having problem figuring out the root cause of this issue. Any pointers are appreciated.

First, the problem is that I have a .mtl template with a conditional that checks whether a String is empty:

|[if (path <> null) and (path.size() > 0)]
|

The exception is:

|org.eclipse.acceleo.engine.AcceleoEvaluationException: Undefined condition of "If" at line 37 in Module CppIncludeUtils
for block if (path.<>(null).and(path.size().>(0))). Last recorded value of self was
TestCDTintegration/Pkg_TestCDTintegration.h.
      at CppIncludeUtils.IncludeDirective(String)(CppIncludeUtils.mtl:37)
      at CppIncludeUtils.IncludeDirective(String)(CppIncludeUtils.mtl:36)
      at CppPackageHeader.CppPackageHeader(Package)(CppPackageHeader.mtl:0)
      at CppPackageHeader.CppPackageHeader(Package)(CppPackageHeader.mtl:15)
|

And it happens because the OCL evaluation of path.size() returns false. This happens because there are two copies of
the ocl String type loaded. Starting at line 555 of EvaluationVisitorImpl (in org.eclipse.ocl):

|    case PredefinedType.SIZE:
         if (sourceType == getString()) {
             // String::size()
             return new Integer(((String) sourceVal).length());
         } else if (sourceType instanceof CollectionType<?, ?>) {
             return new Integer(((Collection<?>) sourceVal).size());
         }
|

I’ve found that sourceType and the result of getString() are different instances. The first comes from loading the
ecore file at org.eclipse.ocl/plugins/org.eclipse.ocl.ecore/model/oclstdlib.ecore the second comes from the in-memory
model
OCLStandardLibraryImpl.INSTANCE.

I’m guessing that the first instance should not have been loaded from the file. It comes from Acceleo’s loading of my
.emtl file. The header has xmlns:ocl.ecore=”http://www.eclipse.org/ocl/1.1.0/Ecore“ and this loads the file instead of
using OCLStandardLibraryImpl.INSTANCE.

If that guess is right, then how do I make that happen?

-Andrew



_______________________________________________
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 <http://www.avg.com>
Version: 2014.0.4355 / Virus Database: 3882/7323 - Release Date: 04/09/14




_______________________________________________
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




begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr";>Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard

Back to the top