With the current K3 annotationProcessor (for an unknown reason) I can reproduce a code generation error in Melange (in the generated adapter code)
After investigation, it appears that:
in the weaveBuilder, Melange gets the JvmDeclaredType from xtend ( WeaveBuilder.xtend#L63)
However, depending on how melange is called, this JvmDeclaredType does not have the same content for a given aspect.
(On my configuration: GEMOC + latest K3 (2018-08-10) + melange in dev workspace, then GEMOC legacyFSM example)
If called due to an editor opening event (for the outline of the melange file) then it returns the java class processed by k3 annotation processor (static method, 1st parameter for self)
If called by "generate interfaces" command, the the JvmDeclaredType corresponds to the class before being processed by K3 (ie. not static, no self as 1st parameter)
then in AspectToEcore.xtend, as it assumes that the file has been processed by K3, it generates a wrong signature for the methods. Leading to wrong modeltype ecore generation and other java errors in the adapters (unimplemented abstract methods, wrong override, ...)
This issue looks similar to previous symptom we observed with non consistent behavior of melange generation (opening or closing the editor helped in having correct code) but without a way to reproduce it systematically for debug. (for ex: #107, #100, #75)
With the current K3 annotationProcessor (for an unknown reason) I can reproduce a code generation error in Melange (in the generated adapter code)
After investigation, it appears that: in the weaveBuilder, Melange gets the JvmDeclaredType from xtend ( WeaveBuilder.xtend#L63)
However, depending on how melange is called, this JvmDeclaredType does not have the same content for a given aspect.
(On my configuration: GEMOC + latest K3 (2018-08-10) + melange in dev workspace, then GEMOC legacyFSM example) If called due to an editor opening event (for the outline of the melange file) then it returns the java class processed by k3 annotation processor (static method, 1st parameter for self) If called by "generate interfaces" command, the the JvmDeclaredType corresponds to the class before being processed by K3 (ie. not static, no self as 1st parameter)
then in AspectToEcore.xtend, as it assumes that the file has been processed by K3, it generates a wrong signature for the methods. Leading to wrong modeltype ecore generation and other java errors in the adapters (unimplemented abstract methods, wrong override, ...)
This issue looks similar to previous symptom we observed with non consistent behavior of melange generation (opening or closing the editor helped in having correct code) but without a way to reproduce it systematically for debug. (for ex: #107, #100, #75)