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

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
> 



Back to the top