On 1/23/2013 1:53 PM, Richard Eckart de Castilho wrote: > Am 23.01.2013 um 19:40 schrieb Marshall Schor <[email protected]>: > >> Although I like the refactoring solution, I think it only covers a subset of >> the >> customizations possible. > What additional customizations do you have in mind?
JCasGen is built on top of EMF's (Eclipse Modelling Framework's) design for supporting combining generated code with handwritten parts. See, for instance, the EMF book (2nd edition), or this bit online of that book (section 2.4.3) [1]. So users are able to do a wide variety of changes/customizations, including replacing some of the generated code, extending interfaces, add or change instance variables, methods, comments, etc. I'm not saying they have done this, but they can. It's a source-code transformation - new source is generated, so the kinds of changes are pretty wide open. -Marshall [1] http://www.informit.com/articles/article.aspx?p=1323360&seqNum=4 > >> I wonder if running JCasGen could be arranged to not update the target if >> there's no change in the source - either literally, or via time-stamps (like >> "make" does). > As I recall, a non-default SVN parameter (use-commit-times = yes) needs to be > set so that the time stamp on a check-out reflects the commit time. Unless > that would be set, the JCas classes would be regenerated at least once after > checkout. Literal regeneration, meaning without any variable parts in the > source, would probably be better. It could be considered to add some special > treatment to detect if the original file and a generated file are equal minus > formatting, so that a file is not updated if the customized version has been > passed e.g. through the Eclipse code formatter. > > -- Richard > >> On 1/23/2013 12:40 PM, Richard Eckart de Castilho wrote: >>> Hi, >>> >>> getting the jcasgen-maven-plugin back on the radar reminds me of an issue >>> that has been bugging me for a while and is the reason why I couldn't >>> currently imagine using such a plugin: >>> >>> It is a feature of the JCas design that JCas wrappers can be customized, in >>> particularly methods can be added. The JCasGen preserves such >>> customizations, but it does add timestamp information to the JCas wrappers. >>> This makes it awkward to run jcasgen as part of the build with customized >>> classes and to keep those classes in SVN - it's just dirty every time. >>> >>> A low-cost solution would be to allow disabling time-stamps in JCas >>> wrappers, just like it is possible for JavaDoc and was recently suggested >>> to save SVN-space. >>> >>> Another more complex solution could be to refactor the JCas system so that >>> the JCasGen generates base classes (purely generated) and customizable >>> classes that inherit from these base classes. The latter would go to SVN >>> while the former would not, e.g. Token_Base and Token. Inheritance would be >>> between the base-classes mainly (e.g. Token_Base extends Annotation_Base). >>> >>> Are there any opinions or alternatives? >
