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,
Right, this is obviously not the recommended way to launch an Acceleo evaluation. You usually have a "main" mtl template (annotated with [comment @main /], see http://www.obeonetwork.com/page/the-acceleo-main-modules) that is recognized by Acceleo as the entry point of a generation. A java class is generated beside this main template, which is what I call the "generated Acceleo launcher". This generated class is a subclass of AbstractAcceleoEngine, and both that superclass and the generated sub-class take care of a lot of the necessary "plumbing". One of these necessary things is what we do in "registerPackages()" (see http://git.eclipse.org/c/acceleo/org.eclipse.acceleo.git/tree/plugins/org.eclipse.acceleo.engine/src/org/eclipse/acceleo/engine/service/AbstractAcceleoGenerator.java#n493) which takes care of registering some widely used packages, notably OCL's "ecorePackage", "expressionPackage" and standard libraries in the resource set that will be used by the generation (some of which may already be registered in the global package registry, but we still do it in case of standalone launches).
You might be interested in looking at all these initialization steps we have in there and reproduce them in your "Driver" ... 

Laurent Goubet
Obeo

On 22/04/2014 21:50, Andrew Eidsness wrote:

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


_______________________________________________
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