Bugzilla – Full Text Bug Listing
| Summary: | Uninstantiable FacadeHelper not diagnosed | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | Ed Merks <Ed.Merks> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 2.7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
It drops down into the EclipseHelper case so failure at this point isn't necessarily even a problem. You don't end up with null pointer exceptions downstream? (Ones obviously caused by there being no facade helper.) My use case was confused. I was was using my StandaloneASTFacadeHelper, that works around bug 308069, to try to write a Java App to exercise genmodel and OCL2Java. That failed totally since JET needs the Java compiler. Unfortunately I continued to use StandaloneASTFacadeHelper with a missing export in a JUnit plugin test. ASTFacadeHelper of course works fine for plugins. However specification of the helper is an explicit direction so I feel that it should not be silently ignored, though with many genmodels out there with silent typos, throwing an Exception would cause compatibility problems. I suggest a Console/Error Log message warning of the problem. [It might also be nice to warn if the template directory does not exist.] An problem is logged for this case. The changes are available in builds. |
If a FacadeHelper for the JControlModel cannot be instantiated, perhaps because its package has not been exported, the potential diagnosis is suppressed by the catch (Exception e) { // Ignore } in CodeGenUtil.instantiateFacadeHelper. The eventual observable phenomenon is that generated Java files terminate after the imports.