[
https://issues.apache.org/jira/browse/UIMA-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697879#comment-13697879
]
Marshall Schor commented on UIMA-2953:
--------------------------------------
Yes, I think this is to be something of a mutual education :-) - having not
used uimaFIT myself :-).
First some minor editing: I assume you mean in Case 1: .... one or more
dedicated Maven modules ... to be ... one or more dedicated UIMA modules ... ?
Second, apologies for this long ramble...
Some clarifications:
* JCasGen always does a complete import of all things (AE descriptors, type
system descriptors, etc.) and uses core UIMA to form the merged type system.
All UIMA-1176 does is limit which cover classes get generated from all of the
defined types.
* I was thinking of the module as typically being an Eclipse "Project" which
contained both annotator implementation Java code, as well as an Analysis
Engine XML Descriptor for that which specified the externalized meta-data for
the Annotator: the type system, the inputs/ outputs, the parameters, any
special indexes, resources, etc.
I was thinking there are 2 use cases - the uimaFIT style, where descriptors are
not used (?) and the UIMA style, using XML descriptors. In the latter, type
systems are put together from collections of specifications. These collections
are done using imports, which occur in two places (for type systems): within
type system descriptions themselves, and also within aggregate analysis
descriptors, where the delegates are typically specified using imports.
So the spec of what things go together is provided in the XML descriptors, via
the import statements. If this exists, that's what I think the ant-like
patterns would be replicating. If this doesn't exist (here I'm guessing -
perhaps because the uimaFIT style isn't using these descriptors), the ant-like
pattern isn't replicating this.
The use case that motivate UIMA-1176 was, as you thought, where people would
create an Eclipse project, and put annotator code plus an annotator analysis
engine description (which, in turn, would include a type system, which perhaps
had imports of other type systems). The JCasGen operation would generate the
source code and put it into this Eclipse project's sources, so that when a Jar
was made for this, it would include both the annotator implementation, and the
corresponding JCas classes (excluding imports of type systems not defined
within this project). This seemed like a modular packaging.
This use-case corresponds to your "Case 2" I think. UIMA-1176 helps case 2,
where the AE module might depend on other similarly packaged Analysis Engines,
and would therefore get their JCas cover classes by depending on these other
projects (which would be defining them).
In "Case 2" - if there were multiple top level descriptors, say for 2
configurations of a particular AE, where the Types produced were different, I
can see where one might want to specify multiple top level descriptors to
jcasgen-maven-plugin. I haven't seen or heard about this use case myself,
however; it seems to me that when people design an annotator, they have a
single idea about what it's producing, and want to provide JCas cover classes
for that. Have you seen this?
For large projects, I've seen "Case 1" style, where a group collectively
decides to put a large collection of types into a "shared" Eclipse project,
which they might call their "model". I can imagine that there might *not* be a
single common type system spec which specified all of the type system
descriptors, and how this could create the need for the build tool to specify
multiple top descriptors.
> 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
