Community
Participate
Working Groups
Build id: 20120202-1513 (Juno M5) Trying to do some generation of OclInEcore-edited .ecore. Great !! the Tutorial.ecore code model generation doesn't fail anymore because of linkage errors. However, the following simple file ends with a generator problem, which silently logs a NPE[1] in the error log: package prueba : prueba = 'http://prueba' { class Clase1 { invariant : self.name.size() > 0; attribute name : String[?] { ordered }; } } The problem is that not specifying a name for the invariant provokes no key creation for the annotation detail entry, and the OCLGenModelGeneratorAdapter assumes the key is present. I don't think EMF will deal with no keys in its detail map. Either you remove the optionality of the invariant name for oclinecore grammar, or you generate any random key for the entry, with any kind of pattern so it doesn't come up in the OclInEcore editor. [1] java.lang.NullPointerException at org.eclipse.ocl.examples.codegen.ecore.OCLGenModelGeneratorAdapter.convertConstraintsToOperations(OCLGenModelGeneratorAdapter.java:140) at org.eclipse.ocl.examples.codegen.ecore.OCLGenModelGeneratorAdapter.doPreGenerate(OCLGenModelGeneratorAdapter.java:229) at org.eclipse.emf.codegen.ecore.generator.AbstractGeneratorAdapter.preGenerate(AbstractGeneratorAdapter.java:250) at org.eclipse.emf.codegen.ecore.generator.Generator.generate(Generator.java:629) at org.eclipse.emf.codegen.ecore.genmodel.presentation.GeneratorUIUtil$GeneratorOperation.execute(GeneratorUIUtil.java:161) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
NPE indeed caused by anaonymous invariant. CD to Pivot can cope, but Pivot to Ecore can't becuase a null name is incompatible with the 'constraints' annotation summary. Changed to just ignore unnamed invariants. Bug 371171 raised to priovide a warning in the editor. JUnit test added. Pushed to master for M6.
The plugin variant of this test fails on Hudson, so it has been disabled. Re-instate once Acceleo moves to Guava.
(In reply to comment #2) > Re-instate once Acceleo moves to Guava. Re-instated, successful build on branch; pushed to master.
CLOSED after a year in the RESOLVED state.
(In reply to Adolfo Sanchez-Barbudo Herrera from comment #0) > package prueba : prueba = 'http://prueba' > { > class Clase1 > { > invariant : self.name.size() > 0; > attribute name : String[?] { ordered }; > } > } Once we add the SymbolicAnalysis, bug 520440, this fails with a mayBeInvalid on self.name. Changing to attribute name : String[1] { ordered }; eliminates the hazard.
(In reply to Ed Willink from comment #5) > Changing to > > attribute name : String[1] { ordered }; > > eliminates the hazard. Yes, but that just makes the problem go away by requiring an EMF lower bound check. Changing to invariant : (self.name <> null) and (self.name.size() > 0); should ensure that the lower bound is checked and guards the size comparison. Just needs the self.name mayBeNull hypothesis for the size call to be detected as a contradiction. (The CG should factor out the CSE.)
