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? > 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? -- ------------------------------------------------------------------- Richard Eckart de Castilho Technical Lead Ubiquitous Knowledge Processing Lab (UKP-TUD) FB 20 Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
