You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Jens Grivolla <j+...@grivolla.net> on 2013/10/04 12:41:37 UTC
uimafit maven plugin: type system imports?
Hi,
I tried using the uimafit maven plugin, in particular the "generate"
goal (trying to make it play nice with the pear packaging plugin).
However, the generated descriptor does not include the type system
imports, even though they are specified through types.txt.
Is there some way to get those imports in the descriptor?
Thanks,
Jens
Re: uimafit maven plugin: type system imports?
Posted by Jens Grivolla <j+...@grivolla.net>.
I don't think having more than one AE per PEAR would work, so the only
solution would be to generate several PEARs from one project / maven
module. This would introduce considerable additional complexity (it
would have to discover all available components, etc.), and at least for
us it's not worth it.
Don't worry about it, having PEAR packaging as something separate
(possibly with modifications to the descriptor, etc.) and needing some
manual steps to do it is no big deal. We might even move away from using
PEARs and instead use uimaFIT based pipeline assembly for most of our
work...
Thanks for your great work,
Jens
On 10/14/2013 11:55 AM, Richard Eckart de Castilho wrote:
> It would be possible to have just one AE per Maven module so uimaFIT generates only one descriptor.
>
> How do you imagine to handle it if a PEAR module contains more than one AE? How would the PEAR work?
>
> -- Richard
>
> On 14.10.2013, at 11:30, Jens Grivolla <j+...@grivolla.net> wrote:
>
>> I gave up on integrating uimaFIT-based builds with PEAR packaging, there are fundamental differences that I don't know how to resolve cleanly, in particular:
>>
>> uimaFIT: 1 maven artifact = N analysis engines = N generated descriptors
>>
>> PEAR packaging maven plugin: 1 mvn artifact = 1 AE = 1 descriptor = 1 generated PEAR
>>
>> I don't think it's worth it to extend the PEAR packaging maven plugin to generate multiple PEARs, so we'll just stick with having PEAR packaging as something separate.
>>
>> I'm actually thinking of separating "components" packaged as PEARs (as described by the XML descriptors) from "analysis engines" (the actual code) packaged as JARs, with separate namespaces. That's pretty much the separation we have right now, but without the separate namespaces. In that case it would be clear that a component is basically a packaged engine (with parameter settings, etc.).
>>
>> I created UIMA-3346 (https://issues.apache.org/jira/browse/UIMA-3346) as for other descriptor based workflows it would still be very useful to have automatically generated descriptors that are ready to use with type system imports.
>>
>> Bye,
>> Jens
>>
>> On 10/08/2013 12:04 PM, Jens Grivolla wrote:
>>> Hi, I'm still having some other problems in getting it to work well with
>>> the pear packaging plugin (naming conventions, descriptor locations,
>>> etc.), so I'm not sure if I can create a fully automated build.
>>>
>>> It would still be nice to not have to edit the descriptor manually, but
>>> since I have to do some manual steps anyway it's not as important to get
>>> it fixed right now.
>>>
>>> I'll create the feature request anyway, as it would be quite useful for
>>> people using CPE, UIMA-AS or other descriptor-based deployments...
>>>
>>> Bye,
>>> Jens
>>>
>>> On 10/04/2013 01:36 PM, Richard Eckart de Castilho wrote:
>>>> It is a known "gap". I deliberately left this out of the current
>>>> version because the auto-detect mechanism (types.txt) may detect much
>>>> more than the component needs. Input/output capabilities are also not
>>>> a reliable source of information, in particular for components in
>>>> which types are configured via parameters.
>>>>
>>>> I don't think it would be difficult to add. Please open a feature
>>>> request if you need this, along with a motivation. If you can spare
>>>> the time, patches are surely welcome. It would probably be good to
>>>> have this enabled by default, but allow to disable it.
>>>>
>>>> Cheers,
>>>>
>>>> -- Richard
>>>>
>>>> On 04.10.2013, at 12:41, Jens Grivolla
>>>> <j+...@grivolla.net> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I tried using the uimafit maven plugin, in particular the "generate"
>>>>> goal (trying to make it play nice with the pear packaging plugin).
>>>>> However, the generated descriptor does not include the type system
>>>>> imports, even though they are specified through types.txt.
>>>>>
>>>>> Is there some way to get those imports in the descriptor?
>>>>>
>>>>> Thanks,
>>>>> Jens
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: uimafit maven plugin: type system imports?
Posted by Richard Eckart de Castilho <re...@apache.org>.
It would be possible to have just one AE per Maven module so uimaFIT generates only one descriptor.
How do you imagine to handle it if a PEAR module contains more than one AE? How would the PEAR work?
-- Richard
On 14.10.2013, at 11:30, Jens Grivolla <j+...@grivolla.net> wrote:
> I gave up on integrating uimaFIT-based builds with PEAR packaging, there are fundamental differences that I don't know how to resolve cleanly, in particular:
>
> uimaFIT: 1 maven artifact = N analysis engines = N generated descriptors
>
> PEAR packaging maven plugin: 1 mvn artifact = 1 AE = 1 descriptor = 1 generated PEAR
>
> I don't think it's worth it to extend the PEAR packaging maven plugin to generate multiple PEARs, so we'll just stick with having PEAR packaging as something separate.
>
> I'm actually thinking of separating "components" packaged as PEARs (as described by the XML descriptors) from "analysis engines" (the actual code) packaged as JARs, with separate namespaces. That's pretty much the separation we have right now, but without the separate namespaces. In that case it would be clear that a component is basically a packaged engine (with parameter settings, etc.).
>
> I created UIMA-3346 (https://issues.apache.org/jira/browse/UIMA-3346) as for other descriptor based workflows it would still be very useful to have automatically generated descriptors that are ready to use with type system imports.
>
> Bye,
> Jens
>
> On 10/08/2013 12:04 PM, Jens Grivolla wrote:
>> Hi, I'm still having some other problems in getting it to work well with
>> the pear packaging plugin (naming conventions, descriptor locations,
>> etc.), so I'm not sure if I can create a fully automated build.
>>
>> It would still be nice to not have to edit the descriptor manually, but
>> since I have to do some manual steps anyway it's not as important to get
>> it fixed right now.
>>
>> I'll create the feature request anyway, as it would be quite useful for
>> people using CPE, UIMA-AS or other descriptor-based deployments...
>>
>> Bye,
>> Jens
>>
>> On 10/04/2013 01:36 PM, Richard Eckart de Castilho wrote:
>>> It is a known "gap". I deliberately left this out of the current
>>> version because the auto-detect mechanism (types.txt) may detect much
>>> more than the component needs. Input/output capabilities are also not
>>> a reliable source of information, in particular for components in
>>> which types are configured via parameters.
>>>
>>> I don't think it would be difficult to add. Please open a feature
>>> request if you need this, along with a motivation. If you can spare
>>> the time, patches are surely welcome. It would probably be good to
>>> have this enabled by default, but allow to disable it.
>>>
>>> Cheers,
>>>
>>> -- Richard
>>>
>>> On 04.10.2013, at 12:41, Jens Grivolla
>>> <j+...@grivolla.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> I tried using the uimafit maven plugin, in particular the "generate"
>>>> goal (trying to make it play nice with the pear packaging plugin).
>>>> However, the generated descriptor does not include the type system
>>>> imports, even though they are specified through types.txt.
>>>>
>>>> Is there some way to get those imports in the descriptor?
>>>>
>>>> Thanks,
>>>> Jens
>>>
>>>
>>
>>
>>
>
>
Re: uimafit maven plugin: type system imports?
Posted by Jens Grivolla <j+...@grivolla.net>.
I gave up on integrating uimaFIT-based builds with PEAR packaging, there
are fundamental differences that I don't know how to resolve cleanly, in
particular:
uimaFIT: 1 maven artifact = N analysis engines = N generated descriptors
PEAR packaging maven plugin: 1 mvn artifact = 1 AE = 1 descriptor = 1
generated PEAR
I don't think it's worth it to extend the PEAR packaging maven plugin to
generate multiple PEARs, so we'll just stick with having PEAR packaging
as something separate.
I'm actually thinking of separating "components" packaged as PEARs (as
described by the XML descriptors) from "analysis engines" (the actual
code) packaged as JARs, with separate namespaces. That's pretty much the
separation we have right now, but without the separate namespaces. In
that case it would be clear that a component is basically a packaged
engine (with parameter settings, etc.).
I created UIMA-3346 (https://issues.apache.org/jira/browse/UIMA-3346) as
for other descriptor based workflows it would still be very useful to
have automatically generated descriptors that are ready to use with type
system imports.
Bye,
Jens
On 10/08/2013 12:04 PM, Jens Grivolla wrote:
> Hi, I'm still having some other problems in getting it to work well with
> the pear packaging plugin (naming conventions, descriptor locations,
> etc.), so I'm not sure if I can create a fully automated build.
>
> It would still be nice to not have to edit the descriptor manually, but
> since I have to do some manual steps anyway it's not as important to get
> it fixed right now.
>
> I'll create the feature request anyway, as it would be quite useful for
> people using CPE, UIMA-AS or other descriptor-based deployments...
>
> Bye,
> Jens
>
> On 10/04/2013 01:36 PM, Richard Eckart de Castilho wrote:
>> It is a known "gap". I deliberately left this out of the current
>> version because the auto-detect mechanism (types.txt) may detect much
>> more than the component needs. Input/output capabilities are also not
>> a reliable source of information, in particular for components in
>> which types are configured via parameters.
>>
>> I don't think it would be difficult to add. Please open a feature
>> request if you need this, along with a motivation. If you can spare
>> the time, patches are surely welcome. It would probably be good to
>> have this enabled by default, but allow to disable it.
>>
>> Cheers,
>>
>> -- Richard
>>
>> On 04.10.2013, at 12:41, Jens Grivolla
>> <j+...@grivolla.net> wrote:
>>
>>> Hi,
>>>
>>> I tried using the uimafit maven plugin, in particular the "generate"
>>> goal (trying to make it play nice with the pear packaging plugin).
>>> However, the generated descriptor does not include the type system
>>> imports, even though they are specified through types.txt.
>>>
>>> Is there some way to get those imports in the descriptor?
>>>
>>> Thanks,
>>> Jens
>>
>>
>
>
>
Re: uimafit maven plugin: type system imports?
Posted by Jens Grivolla <j+...@grivolla.net>.
Hi, I'm still having some other problems in getting it to work well with
the pear packaging plugin (naming conventions, descriptor locations,
etc.), so I'm not sure if I can create a fully automated build.
It would still be nice to not have to edit the descriptor manually, but
since I have to do some manual steps anyway it's not as important to get
it fixed right now.
I'll create the feature request anyway, as it would be quite useful for
people using CPE, UIMA-AS or other descriptor-based deployments...
Bye,
Jens
On 10/04/2013 01:36 PM, Richard Eckart de Castilho wrote:
> It is a known "gap". I deliberately left this out of the current version because the auto-detect mechanism (types.txt) may detect much more than the component needs. Input/output capabilities are also not a reliable source of information, in particular for components in which types are configured via parameters.
>
> I don't think it would be difficult to add. Please open a feature request if you need this, along with a motivation. If you can spare the time, patches are surely welcome. It would probably be good to have this enabled by default, but allow to disable it.
>
> Cheers,
>
> -- Richard
>
> On 04.10.2013, at 12:41, Jens Grivolla <j+...@grivolla.net> wrote:
>
>> Hi,
>>
>> I tried using the uimafit maven plugin, in particular the "generate" goal (trying to make it play nice with the pear packaging plugin). However, the generated descriptor does not include the type system imports, even though they are specified through types.txt.
>>
>> Is there some way to get those imports in the descriptor?
>>
>> Thanks,
>> Jens
>
>
Re: uimafit maven plugin: type system imports?
Posted by Richard Eckart de Castilho <re...@apache.org>.
It is a known "gap". I deliberately left this out of the current version because the auto-detect mechanism (types.txt) may detect much more than the component needs. Input/output capabilities are also not a reliable source of information, in particular for components in which types are configured via parameters.
I don't think it would be difficult to add. Please open a feature request if you need this, along with a motivation. If you can spare the time, patches are surely welcome. It would probably be good to have this enabled by default, but allow to disable it.
Cheers,
-- Richard
On 04.10.2013, at 12:41, Jens Grivolla <j+...@grivolla.net> wrote:
> Hi,
>
> I tried using the uimafit maven plugin, in particular the "generate" goal (trying to make it play nice with the pear packaging plugin). However, the generated descriptor does not include the type system imports, even though they are specified through types.txt.
>
> Is there some way to get those imports in the descriptor?
>
> Thanks,
> Jens