uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-2953) jcasgen-maven-plugin needs to support patterns
Date Tue, 02 Jul 2013 15:22:22 GMT

    [ 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

Mime
View raw message