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 <[email protected]> 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
<[email protected]> 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
