Community
Participate
Working Groups
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.
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.