Yes, that's why I felt custom subclasses could be a good compromise: JCasGen handled by Maven, user customizations as subclasses that are kept under version control.
On Wed, Nov 23, 2016 at 10:24 AM, Marshall Schor <m...@schor.com> wrote: > good point... > > -Marshall > > > On 11/23/2016 8:35 AM, Richard Eckart de Castilho wrote: > > On 22.11.2016, at 21:33, Marshall Schor <m...@schor.com> wrote: > >> Yes, I believe that is correct - the Maven plugin does not support > "merging" > >> with already generated customized JCasGen cover classes. > >> > >> If that was a requirement, I suspect (with some work, and dependencies > such as > >> you need to have an Eclipse installation...) it could be added. > > I don't think that fits in well with a Maven-based build, does it? > > I mean, customized code would be under version control. If JCasGen > > would run over that and update it, then the code would always be > > dirty... Using JCasGen in a Maven build for customized classes would > > require a strategy to somehow separate the generated code and the > > customized aspects, such that the first is under version control > > but not that latter. > > > > Cheers, > > > > -- Richard > >
