Re: [mdt-ocl.dev] multiple instances of oclstdlib

[Andrew Eidsness <eclipse@xxxxxxxxxx>]

Sorry about the delay but I'm looking into this more now.

How would I check if its using the generated launcher?  I think it is using
org.eclipse.acceleo.model.mtl.resource.AcceleoResourceSetImpl, but I don't see OCL standard library being registered.
This resource set is being used by what looks like a non-generated AcceleoDriver
(http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/extraplugins/codegen/org.eclipse.papyrus.acceleo/src/org/eclipse/papyrus/acceleo/AcceleoDriver.java).

Where would I look to find the generated one?

-Andrew

On 14-04-11 03:11 AM, Laurent Goubet wrote:
> 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
>>
> 
> 
> 
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>