| Re: [mdt-papyrus.dev] discusion relative to maven integration in papyrus |
|
Hi, Ø
Right, but does this mean that they (a) won’t implement code generation in the build, (b) that only the files that need custom code will be check in to git and the rest will be generated in the build (and those that are checked
in re-generated), or (c) that we are looking for or inventing a solution that lets the custom code be factored out of the generated code in EMF models? In the specific case of Notation extensions, the generated code doesn’t compile, so we can’t reuse the src-gen + custom-src pattern: we’re not extending the
behavior, only fixing compile errors due to inconsistencies between the modern GenModel and the one used to generate Notation (And which doesn’t seem to exist anymore). So I think all Notation extensions should be completely excluded from this scope of this builder. The clean solution would be to either generate the Notation
metamodel in GMF, or to tweak the GenModel options/generator for the extensions, but this seems to be a lot of effort for very little gain (Implementing a code generator for a single small use case is not worth it :) ) Ø
Heh heh. I didn’t know it was that much easier. I always found Buckminster simple to set up, run, and maintain, myself. But then, that wasn’t in projects of the size of Papyrus. :-) I didn’t spend much effort in learning Buckminster. I didn’t spend much effort in learning Tycho as well. But in the latter case, I’ve been able to produce
some results :) I’m not sure how the two tools compare when properly used, but at least the learning curve for Tycho was faster for me. And for developers who never used Buckminster or Tycho, they are now able to trigger a local build in a single click from
Eclipse, without any specific knowledge about the build technology. Maybe Buckminster allows the same thing, but this has never been implemented in Papyrus AFAIK (Or maybe it has been, but not maintained?).
Camille De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian W. Damus Hi, Camille,
Ø
(as an aside, do we have a good story for the EMF codegen situations that require editing generated code?) All metamodels based on the GMF Notation metamodel, which doesn’t come with a GenModel. Especially the generated code for the Model Import tool and Viewpoints
can’t be compiled immediately. They need manual fixes. Right, but does this mean that they (a) won’t implement code generation in the build, (b) that only the files that need custom code will be check in to git and the rest will be generated in the build (and those that are checked in re-generated),
or (c) that we are looking for or inventing a solution that lets the custom code be factored out of the generated code in EMF models?
Heh heh. I didn’t know it was that much easier. I always found Buckminster simple to set up, run, and maintain, myself. But then, that wasn’t in projects of the size of Papyrus. :-) Cheers, Christian |