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 >>> >>> >> >> >> > >
