[
https://issues.apache.org/jira/browse/UIMA-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697244#comment-13697244
]
Marshall Schor commented on UIMA-2953:
--------------------------------------
Can we clarify the use case for wanting more than 1 top level descriptor as
input to the JCasGen Maven plugin? It seems to me that having this might
create a parallel specification (using ant-like specifications) for aggregating
type systems, replicating what's already in the UIMA XML specifications.
The original use case for this I think was to have similar functional
capability as is in the UIMA Fit class JCasGenPomFriendly class. The Javadocs
there motivate this capability by saying "Being able to process multiple type
system descriptors at the same time removes the need of having a single master
type system file importing all others."
When using UIMA, type aggregation occurs via both "importing" of other type
systems within a type system descriptor, and also by having aggregate analysis
engines, specifying delegates, which, in turn, may have embedded type system
descriptors.
The use case of using UIMA without UIMAfit would have XML descriptors
corresponding to the components, type systems, aggregates, etc., and would have
a design which specified some "aggregation" pattern that made sense for the
particular use case, where design issues like which subsets of components are
candidates for reuse in other contexts come into play. This design would be
reflected (and documented) in the UIMA XML descriptors. It would be a
maintenance issue if, in addition to this, an alternate aggregation (using
ant-like patterns) was specified in a maven build.
Is this (the ant-style aggregation of type system descriptor files) something
needed by UIMAfit users only, and is it OK for it to support only the
import-style (not the aggregate analysis engine with delegates style) of
aggregation?
> jcasgen-maven-plugin needs to support patterns
> ----------------------------------------------
>
> Key: UIMA-2953
> URL: https://issues.apache.org/jira/browse/UIMA-2953
> Project: UIMA
> Issue Type: Improvement
> Components: jcasgen-maven-plugin
> Reporter: Richard Eckart de Castilho
> Assignee: Richard Eckart de Castilho
> Fix For: 2.4.1SDK
>
>
> With the old JCasGenPomFriendly class in uimaFIT, it was possible to select
> the descriptors for which JCas wrappers should be generated using a wildcard
> pattern:
> {noformat}
> <configuration>
> <mainClass>org.apache.uima.fit.util.JCasGenPomFriendly</mainClass>
> <arguments>
>
> <argument>file:${project.basedir}/src/test/resources/org/apache/uima/fit/type/**/*.xml</argument>
> <argument>${project.build.directory}/generated-sources/jcasgen</argument>
> </arguments>
> <classpathScope>test</classpathScope>
> </configuration>
> {noformat}
> With the current jcasgen-maven-plugin, only a single descriptor file is
> possible. This is quite inconvenient for users. At least there should be the
> same possibility of specifying a wildcard pattern as in the
> JCasGenPomFriendly. Even better would be, to combine that with the commonly
> used include/exclude pattern used in many Maven plugins, e.g.
> {noformat}
> <plugin>
> <groupId>org.apache.uima</groupId>
> <artifactId>jcasgen-maven-plugin</artifactId>
> <executions>
> <execution>
> <goals>
> <goal>generate</goal>
> </goals>
> <configuration>
> <typeSystemIncludes>
>
> <typeSystemInclude>src/main/resources/types/**/*.xml</typeSystemInclude>
> </typeSystemIncludes>
> <typeSystemExcludes>
>
> <typeSystemExclude>src/main/resources/types/**/nojcas/*.xml</typeSystemExclude>
> </typeSystemExcludes>
> </configuration>
> </execution>
> </executions>
> </plugin>
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
