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 wrote:
> good point...
>
> -Marshall
>
>
> On 11/23/2016 8:35
good point...
-Marshall
On 11/23/2016 8:35 AM, Richard Eckart de Castilho wrote:
> On 22.11.2016, at 21:33, Marshall Schor wrote:
>> Yes, I believe that is correct - the Maven plugin does not support "merging"
>> with already generated customized JCasGen cover classes.
>>
>>
On 22.11.2016, at 21:33, Marshall Schor 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
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.
-Marshall
On
I was making some incorrect assumptions.
I was assuming that the parent JCasGen'd class would correspond to a UIMA type,
and the subclass would be something that extended that but didn't add any
features, or needed to get registered, etc.
The only reason to register it would be to have non-JCas
Hi,
I think there is a problem with customized JCasGen cover classes. The
maven plugin does not support it but just generates new classes.
Best,
Peter
Am 21.11.2016 um 22:27 schrieb Marshall Schor:
> On 11/19/2016 1:10 PM, Pablo Duboue wrote:
>> Can we support generated classes being
On 21.11.2016, at 23:12, Marshall Schor wrote:
>
> there's plenty of denseness to go around :-) I think this ought to work in v2
> as well? Can you say a scenario where it wouldn't?
In V2, one would at least have to manually implement the typeIndexID+friends in
the subclass,
My recollection is that JCasGen tend to make things private and final,
but I haven't looked at the generated classes in a while (by virtue of
keeping them in generated-sources).
P
On Mon, Nov 21, 2016 at 5:12 PM, Marshall Schor wrote:
> there's plenty of denseness to go around
there's plenty of denseness to go around :-) I think this ought to work in v2
as well? Can you say a scenario where it wouldn't?
-Marshall
On 11/21/2016 4:49 PM, Richard Eckart de Castilho wrote:
> Sorry, probably I'm being dense ;) So for V2, I'm pretty sure that this
> didn't "just work",
Sorry, probably I'm being dense ;) So for V2, I'm pretty sure that this
didn't "just work", but I gather you say that for V3, this really does
work?
Cheers,
-- Richard
> On 21.11.2016, at 22:46, Marshall Schor wrote:
>
> I'm probably being dense, but I'm not sure why it
I'm probably being dense, but I'm not sure why it wouldn't just work:
Foo : a JCas gen'd class
SubFoo extends Foo - the subclass
new SubFoo(jcas) would create a new feature structure, assuming the constructor
called its superconstructor (as is normally the case).
On 21.11.2016, at 22:27, Marshall Schor wrote:
>
> On 11/19/2016 1:10 PM, Pablo Duboue wrote:
>> Can we support generated classes being handled by maven while the user
>> provides custom subclasses?
> We currently have a maven plugin that runs JCasGen, so, yes, I think this is
>
On 11/19/2016 1:10 PM, Pablo Duboue wrote:
> Can we support generated classes being handled by maven while the user
> provides custom subclasses?
We currently have a maven plugin that runs JCasGen, so, yes, I think this is
possible, even now.
-Marshall
> At least we should support realizing there
Can we support generated classes being handled by maven while the user
provides custom subclasses?
At least we should support realizing there are custom files in src and
modify them there rather than generated-sources.
Rationale:
JCasGen output is big and computer generated. Without
14 matches
Mail list logo