Comment 1 Laurent Goubet 2011-05-13 06:56:01 EDT

Ed,

When you say "operation lookup failure", is it at runtime (you launch Acceleo generations, and get unexpected errors) or with the compilation (compilation errors on valid modules)?

None of our unit tests has shown this, seems like we might be missing important use cases in these.

Comment 2 Ed Willink 2011-05-13 06:59:06 EDT

No. It's the editor that shows cannot resolve. Downstream I get unknown URL exceptions from the standalone execution, but I presume that if the editor/builder is failing, subsequent execution errors are not interesting.

Comment 3 Ed Willink 2011-05-14 05:29:50 EDT

This appears to be fixed in N201105140106, which would suit me fine as an RC1.

Comment 4 Ed Willink 2011-05-14 08:45:46 EDT

(In reply to comment #3)
> This appears to be fixed in N201105140106, which would suit me fine as an RC1.

Wierd; works well in two workspaces, but still has the old problems in a third, despite many cleans.

Comment 5 Ed Willink 2011-05-17 12:57:55 EDT

(In reply to comment #4)
> Wierd; works well in two workspaces, but still has the old problems in a third,
> despite many cleans.

Wierdness is reproducible.

If org.eclipse.ocl.ecore is open as a project in the workspace another of the error messages is "Invalid URL Type: String should be String". If org.eclipse.ocl.ecore is closed the errors go away.

It seems there is some meta-model schizophrenia between the project and the plugin.

Comment 6 Ed Willink 2011-07-05 01:45:54 EDT

This may be the same as Bug 351137 which has a trivial repro.

Comment 7 Ed Willink 2011-09-27 11:53:12 EDT

Probably the same problem arises if I write a transformation using http://www.eclipse.org/emf/2002/GenModel as the meta-model. This presents a challenge since GenModel.ecore uses ../../org.eclipse.emf.ecore for model references to Ecore.ecore and http://www.eclipse.org/emf/2002/Ecore for values.

Therefore depending whether org.eclipse.emf.ecore and org.eclipse.emf.codegen.ecore are absent/open/closed in the workspace, whether access is from the editor/builder/java-launch/acceleo-launch, XMI/binary there are a huge number of possibilities. They all seem reasonable, but a fair few have problems.

The particular case of org.eclipse.emf.codegen.ecore open, org.eclipse.emf.ecore absent, gives a mysterious resolve failure in the editor for genPackage.ecorePackage.name and a prolific number of error log warnings for 

org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: java.io.FileNotFoundException: ..\..\org.eclipse.emf.ecore\model\Ecore.ecore (The system cannot find the path specified)

without any further help or explanation.

Comment 8 Ed Willink 2011-10-25 14:37:15 EDT

(In reply to comment #5)
> If org.eclipse.ocl.ecore is open as a project in the workspace another of the
> error messages is "Invalid URL Type: String should be String". If
> org.eclipse.ocl.ecore is closed the errors go away.
> 
> It seems there is some meta-model schizophrenia between the project and the
> plugin.

3.2RC2 This is now a major problem for me. The OCL2Java is ready to ship in M3 but I cannot build; my workaround of closing org.eclipse.ocl.ecore is not valid for an Update Site (or Hudson build). Therefore my build of ocl2java has compilation errors that do not appear until the transform is run.

I currently see numerous double errors such as

Cannot find operation (invoke(String, String, Sequence(Element))) for the type (Element) Cannot find operation (invoke(String, String, Sequence(Element))) for the type (Element)

Comment 9 Ed Willink 2011-10-25 17:18:07 EDT

(In reply to comment #8)
> 3.2RC2 This is now a major problem for me.

I found a workaround; treat the *.emtl files as sources from a tweaked build, then use the Java builder to copy them from src to bin in a build that has no Acceleo builder/nature/build.acceleo/customBuildCallBacks.

Comment 10 Ed Willink 2011-10-26 05:02:42 EDT

Some insdight into these problems may be gained from alternative EMTLs produced without any apparent error; apart fropm a subsequent failure to execute.

The good snippet is:

          <letVariable name="ePackage">
            <eType xsi:type="ecore:EClass" href="http://www.eclipse.org/emf/2002/Ecore#//EPackage"/>
            <initExpression xsi:type="ocl.ecore:PropertyCallExp">
              <eType xsi:type="ecore:EClass" href="http://www.eclipse.org/emf/2002/Ecore#//EPackage"/>


but a rebuild in different context gave

          <letVariable name="ePackage">
            <eType xsi:type="ecore:EClass" href="http://www.eclipse.org/emf/2002/Ecore#//EPackage"/>
            <initExpression xsi:type="ocl.ecore:PropertyCallExp">
              <eType xsi:type="ecore:EClass" href="../../org.eclipse.emf.ecore/model/Ecore.ecore#//EPackage"/>


which is not in itself wrong, if the URI deresolution is with respect to platform:/plugin/some-plugin/model/some-model.ecore

but since there is also a 

    <imports href="../common/ePackageQueries.emtl#/0"/>

URI deresolution has (correctly) occurred with respect to

    platform:/resource/org/eclipse.ocl.examples.codegen/src/org/eclipse/ocl/examples/codegen/ecore/ocl2java4genmodel.mtl

Not surprisingly the ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EPackage fails to resolve for execution.

Comment 11 Ed Willink 2011-10-26 05:14:47 EDT

(In reply to comment #10)
> Not surprisingly the ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EPackage
> fails to resolve for execution.

The bad build occurs when org.eclipse.emf.ecore is a closed project.

The good build when org.eclipse.emf.ecore is an open project.

So to get 'interactive' OCL builds to work:

org.eclipse.emf.ecore must be an open project.
org.eclipse.ocl must be a closed project.

Comment 12 Ed Willink 2012-04-20 12:57:25 EDT

I think I've found it.

If org.eclipse.ocl.ecore is an open project, the 'helpful'/inefficient scan of all available models loads the OCL Standard Library dynamically creating meta-model schizophrenia with respect to the explicit static load.

This seems to be already known for mtlstdlib at registerEcorePackageHierarchy.registerEcorePackageHierarchy. Changing 

			if (!"mtl".equals(ePackage.getNsPrefix()) && !"mtlnonstdlib".equals(ePackage.getNsPrefix()) //$NON-NLS-1$ //$NON-NLS-2$
					&& !"mtlstdlib".equals(ePackage.getNsPrefix())) { //$NON-NLS-1$

to

			if (!"mtl".equals(ePackage.getNsPrefix()) && !"mtlnonstdlib".equals(ePackage.getNsPrefix()) //$NON-NLS-1$ //$NON-NLS-2$
					&& !"mtlstdlib".equals(ePackage.getNsPrefix()) && !"oclstdlib".equals(ePackage.getNsPrefix())) { //$NON-NLS-1$

fixes the problem.

Comment 13 Stephane Begaudeau 2012-04-23 07:57:58 EDT

I've contributed your fix on HEAD and R3_2_maintenance.

Comment 14 Ed Willink 2012-05-09 08:47:59 EDT

3.3M7 looks good for me.

Comment 15 Stephane Begaudeau 2012-06-05 04:50:58 EDT

working now

Comment 16 Laurent Goubet 2015-05-27 08:57:47 EDT

Closing resolved bugs