Community
Participate
Working Groups
This is partially a duplicate of Bug 378958 that diverted to other issues. Use of a nested workflow such as: Workflow { component = @GenerateLPG { syntaxName = "EssentialOCL" grammarPath = "platform:/resource/org.eclipse.ocl.examples.xtext.essentialocl/src/org/eclipse/ocl/examples/xtext/essentialocl/EssentialOCL.xtext" lpgExe = "${lpgExe}" lpgIncs = "${lpgIncs}" lpgOpts = "${lpgOpts}" } ... works fine until the project build path is tidied up to exclude the copy of src/**/*.mwe2 to bin. Workaround: live with the extra bin clutter. Please ensure that *.mwe2's are resolved from the classpath src.
Referenced workflows are resolved from the classpath. There is no notion of src at runtime, thus I'll mark this as won't fix.
Yes. Not a regression, started typing before a DUP appeared. But if resolution is from the classpath why does the MWE editor successfully resolve them when they are only in the src folder? This is the really confusing thing. MWE2 editor works, run-time fails. Maybe you want to reverse the bug into a missing MWE warning that the workflow is not on the classpath.
(In reply to Ed Willink from comment #2) > Yes. Not a regression, started typing before a DUP appeared. > > But if resolution is from the classpath why does the MWE editor successfully > resolve them when they are only in the src folder? For the same reasons Java source files are resolvable from a Java editor. But if you don't compile them (read: copy the runtime artifacts to bin), they are not available at runtime. > This is the really > confusing thing. MWE2 editor works, run-time fails. Same thing would happen with disabled auto-build - which is an analogy to filtering mwe2 from the bin filder. > > Maybe you want to reverse the bug into a missing MWE warning that the > workflow is not on the classpath. That's be an option.
