Another important topic:
Migrating from pre-Apache UIMA, including timelines, support intentions,
etc.
Some thoughts I'm having about improving the web pages. Here's some
changes I think are needed, in no particular order.
1) Something to say what the various versions are, where they are, why
I'm moving this to the incubator general list.
Marshall Schor wrote:
There seem to be (at least) 2 wiki systems in use at Apache.
One is based on moin-moin (python), and is for instance, found at
wiki.apache.org/incubator-yoko
Another one is based on confluence's wiki, and is found
We have to get patches working in any case. Do attachments work?
-Marshall
Thilo Goetz wrote:
Let's wait another day for your SVN accounts. uuencode really takes
me way back to the early 90s. I had no idea it still existed ;-) If
for some reason your SVN accounts fail to be set up
How should we organize svn?
We can have one trunk/branch/tag and under it a bunch of projects.
We can have multiple top-level things, each having (optionally)
trunk/branch/tag and under those a bunch of projects.
I say optionally, because I see projects that have sandbox as one of
the
To me, the SDK has a meaning of adding tools, examples, etc. to a core
thing. Using it as a top-level collection name for the various
framework implementations seems a bit off.
I think our big code bases (Java, C++, maybe others in the future - e.g.
C#, javaScript) could go into their own
Michael Baessler wrote:
But if I'm honest after this long discussion I do not remember all the
details of each of the
suggestions. I would like to have a summary of the two suggestions and
than start a vote for it.
Many projects save votes for those times where there is not a clear
consensus.
Thinking about our customer base, what would be least confusing to them? I
think calling this release Apache UIMA 2.1 (Incubating) would be good
because:
1) it signals that 2.0.x is the end of the line for that series, new
work is on Apache
2) it signals that Apache UIMA is the release that
I also generally prefer lower case, but make an exception for
brand-things where it might
make a difference.
In this case, I don't feel very strongly about captialization
-Marshall
Adam Lally wrote:
On 11/15/06, Marshall Schor [EMAIL PROTECTED] wrote:
We should obviously remove IBM
Should the manual say a sofa named xxx has an associated cas view,
also named xxx, and that these names can be mapped to different
names by containing aggregates or CPE descriptors?
In particular: looking for what to say about cas views versus sofas.
-Marshall
XCAS is used as
a) the generic name for an externalized CAS
b) a specific format for the externalized CAS (not XMI).
In the documentation, should we use XCAS in the (a) sense, or substitute
XMI-formatted-CAS (or another term?) for it?
-Marshall
I made a minor change to the website to point to the uima wiki correctly.
Also rewrote the top page with a bit more explanation about what is UIMA
- it's viewable if you browse
http://incubator.apache.org/uima/index-draft.html
If it's OK, I'll switch it to index.html so it will come up as the
Thanks for your honest feedback :-) It's a good thing
*trade-marked*.
Thilo Goetz wrote:
snip
To be honest, I don't like your changes to our home page so much. It
sounds too much like our original proposal now, the one where people
didn't know what we were talking about.
I
Adam Lally wrote:
I propose that we try to use JIRA for which issues need to get fixed
for which versions, rather than keeping a separate list on the Wiki
(http://cwiki.apache.org/UIMA/todo.html).
OK. I agree we need to have data in one place, rather than multiple places,
for maintainability.
The process method in v1 takes 2 args. in V2 it takes just one arg -
the result specification arg is now available using
getResultSpecification() assuming someone has called the
setResultSpecification() and the annotator impl has saved this in a
local variable. Is this correct?
I'll start
Web page is here: http://cwiki.apache.org/UIMA/v2vsv1.html
Please correct/augment/improve :-)
Marshall Schor wrote:
I'll start a web page on the wiki to collect documentation re: changes
in v2.
-Marshall
I don't feel strongly but have a slight preference for this kind of info
to be communicated via email.
This is for 2 reasons:
1) it needs to be read in a timely way - and email is more timely
than wiki reading. (although people might
subscribe to wiki changes)
2) it doesn't need to
Thilo Goetz wrote:
You're welcome to this job :-) from my point of view.
-Marshall
All,
if we want to cut a release early next year, we need to get all our
ducks in a row. My impression from following incubator-general is
that getting the release right is a *lot* of work. It is common
Hi everyone -
If you use all the workflow states, a simple fix generates these emails:
[jira] created
[jira] commented (n times - maybe, but n can be 0)
[jira] assigned
[jira] Work started:
svn commit:
[jira] Work stopped
[jira] Resolved
[jira] Closed
I propose we reduce our email reading
On the general @ incubator list, robert burrell donkin wrote:
snip good open source release notes tend to have a different tone from
close source ones
one major aim of the release notes should be to encourage downstream
users (and in particular packagers) that your product is important and
Seems this content might be combinable with existing page: Documentation
- Differences between Version 2 and Version 1?
-Marshall
Adam Lally wrote:
When I did the removal of our xi:include support (issue UIMA-9) I also
added a Wiki page where we can keep track of things like this which
will
This reorg is moving many files around, resulting in a hopefully
easier-to-understand, more rational structure. I hope to finish this
weekend. Until then it would be good to avoid editing the files in the
docbook project.
Thanks. -Marshall
We have the script xcasAnnotationViewer. Because XCas's are deprecated
in v2, should this be renamed to just annotationViewer?
Should we keep the old one (for backwards compatibility)?
-Marshall
Can you update the wiki (and the main website too) so that users who
click on sandbox are directed to a page with some explanation - what
is this, how should it be used, what are the rules for it, etc. I'd
look at other apache projects for guidance here.
Thanks. -Marshall
To support chunking as used in OmniFind, the reference chapter for the
CPE says things like:
termthrottleID/term
listitempara[String] special attribute currently used by
OmniFind./para/listitem
It seems a bit strange to have Omnifind specific information in the
Apache UIMA documentation.
After looking again, it seems that the correct xmlns for XInclude is the
2001 one. There is a note in a book which says this was changed to 2003
at one point, but then changed back.
The Xerces impl has a FAQ which now says:
Will the XInclude processor process include elements from the
Adam Lally wrote:
I got Sun JDK 1.4.2 to work. However it requires an additional jar
file to be added to uima-docbook/lib: the xml-apis.jar that comes
with the Xerces download. Otherwise you get a NoClassDefFoundError
Should I check this in?
yes - but be sure to check in the right one...
Jörn Kottmann wrote:
snip For the uima case there is a work-around
(Eclipse-BuddyPolicy: dependent) inside eclipse, but this must be
enabled in the uima eclipse plugin descriptor. Currently it is not.
Version 2 releases of UIMA include in the UIMA Eclipse Runtime plugin
manifest this line:
Adam Lally wrote:
Yes, this topic again...
While working on a utility to migrate code from IBM UIMA to Apache
UIMA, I encountered the case where the user's project has a definition
of com.ibm.uima.jcas.tcas.DocumentAnnotation. That's because JCasGen
creates this, to account for cases where the
Adam Lally wrote:
On 12/18/06, Marshall Schor [EMAIL PROTECTED] wrote:
It seems to me that developers choose to put data into a CAS because
they envision sharing
that data with other (independently-developed) components. If they're
planning
to do that, then the definitions of the types they're
Jörn Kottmann wrote:
snip Some source files ( 10) are derived from eclipse code. I have
always documented this in the header.
All other code was written by me. I can just remove theses files for
the contribution and than rewrite them.
Derived files are e.g. drag handler, drop handler, copy
Adam Lally wrote:
On 12/18/06, Marshall Schor [EMAIL PROTECTED] wrote:
I think what we have is annotator A might have a version of types for it
(T/A) and
annotator B might have a version of types for it (T/B). The assembly
of A and B
has a process whereby T/A and T/B are merged, and a new T/AB
If we think of a CasView as a way of accessing a subset of the data
in the CAS, what are the pluses and minuses of having every view
have the same (shared) index definitions? Would it make more sense
to have each view have its own non-shared set of indexes / definitions?
Pluses:
- A view which
I like the idea of having the FS creation be off of the base CAS, and
the indexing be with respect to a CasView.
Adam Lally wrote:
There hasn't been any activity on this mail thread (Always pass base
CAS to process method) in a couple of days so I thought I would
restart discussion with a
Re: Need for Global indexes
Adam Lally wrote:
snip
Moreover, I think the reverse direction should be true -- indexing an
FS in a view's index repository DOES add it (at least conceptually) to
indexes that apply to the CAS as a whole. I liked this latter idea
because it provided a way to
Adam Lally wrote:
On 12/22/06, Marshall Schor [EMAIL PROTECTED] wrote:
If we had filtering predicates as part of an index specification,
then we
could create indexes over subsets of types quite arbitrarily. Could this
more general mechanism serve this purpose better than views?
I'm not sure
Thilo Goetz wrote:
Marshall Schor wrote:
Adam Lally wrote:
On 12/22/06, Marshall Schor [EMAIL PROTECTED] wrote:
If we had filtering predicates as part of an index specification,
then we
could create indexes over subsets of types quite arbitrarily. Could
this
more general mechanism serve
I'm starting to look at converting JCas to an interface, with an impl.
First issue found:
this class contains static methods used by JCasGen-erated code, for
factored-out,
common methods to report errors, etc.
(e.g. when getting a feature, there's code like:
if (featOkTst casFeat_ ==
out the common interface definitions for CAS interface and
JCas interface - a lot of them should be the same. It would be nice to
have this clearly partitioned, logically :-)
-Marshall
Marshall Schor wrote:
I'm starting to look at converting JCas to an interface, with an
impl. First issue
Next issue with fixing JCasGen -
The pre-Apache code base had a tool, called uimaj_jet_expander - which
ran against templates and included templates that were part of the
uimaj_jcasgen_gen code.
I can't see the jet_expander tool in the apache source - did it not come
over? If not, any
Jörn Kottmann wrote:
Hi,
it would be nice to have a facility to listen to changes made to a CAS
object.
In a SWT/RCP application its likely that multiple views display
concurrently some aspects of the CAS object,
if now one view makes a change to the CAS object all other views must
be
CASImpl has a hashmap sofa2jcasMap. I think it is superfluous. It is
used in the method
getJCas(SofaFS).
But I think that method can be replaced with a new definition that
doesn't use this map:
getView(SofaFS).getJCas();
Is there a reason we want to have this other hash map?
-Marshall
It appears these some of these methods which are public in the CAS impl
were missing in the interface, and missing in the interface/impl in the
JCas.
I'm adding them - if this is wrong, let me know :-)
-Marshall
Thilo Goetz wrote:
Changes look ok, but I'm wondering: we now have CAS, CommonCas,
AbstractCas and AbstractCas_ImplBase, all in org.apache.uima.cas. Why
is AbstractCas_ImplBase in the interfaces package? Can we please move
it to the appropriate impl package? Any chance we can consolidate
Thilo Goetz wrote:
I'm starting to port the CVD documentation to DocBook. For my XML
editing, I use the Eclipse WebTools, which can give me great syntax
support -- if it can find the DTD. This works when I change the DTD
address from
http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd
Hi Thilo -
I could never figure out what the purpose of the name attribute on the
project... tag was. Is this just for some
informal user documentation, or is it used somewhere?
When I created the docbook project, I started with the Jakarta Velocity
docbook package. This property seemed
Eddie - there are 40 references to this class - but I'm wondering if
these need fixing if we're getting rid of TCAS?
-Marshall
Adam Lally wrote:
Yes, I'll fix those. The only ones I see are in AnalysisEngine.java.
Are there others I'm missing?
When I scan the code for ResultSpecification) I get about 40 hits.
Some of these are comments like this in test cases.
Some are instances that are actually OK.
There's a
More on hierarchies of implementation objects, and saving the user from
writing dereferencing chains:
Suppose we divide the CAS methods into those which would just not make sense
on the CasView API, and others. In the same spirit of pleasing the
users by avoiding what they
could see as
Components: Website
Reporter: Adam Lally
Assigned To: Marshall Schor
Priority: Minor
Clicking the Building with Maven link on the nav bar brings me to the top of the
Source Code page. The intention was to link to a section in the middle of the page
Jörn Kottmann wrote:
Hello,
can we start now to move the tae code over to apache uima ?
I checked with our mentors and they say to also do a software grant
since this is code that was developed outside of Apache coming in.
http://www.apache.org/licenses/software-grant.txt
The whole process
Adam Lally wrote:
snip I thought now might be a good time also to discuss if we want to
rename tae to something else when the code is uploaded. In UIMA we
already use the acronym TAE to mean Text Analysis Engine. This
usage may be on its way out (preferring Analysis Engine instead) but
still I
Thilo Goetz wrote:
snipUnfortunately, the low-level CAS is missing the base CAS
functionality. All the sofa/view stuff was implemented at the CAS
level only. This is something that should be fixed.
My understanding of the low-level interfaces is that they are there to
support the
Thilo Goetz (JIRA) wrote:
snipThis should be revisisted once we know what our distribution layout will
be like, and what a good way is to get at the manuals.
I think Adam has already set up a distribution layout. Adam - can you
put this info up (if it's not already up) somewhere on our
Thilo Goetz wrote:
I have finished porting the CVD manual to DocBook. I'm not too happy
with the result, but I guess it's not much worse than the LaTeX
version. I spent a lot of time trying to get the screenshots to look
right, with very little to show for it.
I did not manage to get small
The LICENSE file is the Apache 2.0 license.
The README says The Snowball stemmers are licensed under
the BSD License (see http://snowball.tartarus.org/license.php), with
Copyright (c) 2001,
Dr Martin Porter, and (for the Java developments) Copyright (c) 2002,
Richard Boulton.
The license
I wonder if things like the Whitespace Annotator in the sandbox should
use org.apache.uima as the start of their package names.
I think this is fine if the thing is destined to be an incorporated part
of the uima java project.
Should it be something else, otherwise?
-Marshall
Thilo Goetz wrote:
Marshall Schor wrote:
The LICENSE file is the Apache 2.0 license.
The README says The Snowball stemmers are licensed under
the BSD License (see http://snowball.tartarus.org/license.php), with
Copyright (c) 2001,
Dr Martin Porter, and (for the Java developments) Copyright (c
Adam Lally wrote:
On 1/4/07, Thilo Goetz [EMAIL PROTECTED] wrote:
I would propose the following changes:
- Leave createFeaturePath() and friends at the CAS. These methods
require/return CAS-specific data structures and don't need to be
accessible anywhere else.
Marshall had already moved
Lev Kozakov wrote:
snip
I thought that your intention was to emphasize that the old TAE output
format is not available any more.
I'm not trying to emphasize. I thought, from previous comments, that
there
was a flag, called -ae, which could be set true or false.
So I thought there might be
Adam Lally (JIRA) wrote:
snip Currently there is a distinction made for single view and multiple view
components. The UIMA architecture standard proposes that all components are multiple view components and be
delivered a handle to the base CAS, and the component retrieves views as required.
Adam Lally wrote:
There's another issue with JCas we haven't considered yet - the
addToIndexes() method on JCasGen-erated classes. When this is called,
it needs to know what index repository (what view) to index them in.
Same for removeFromIndexes() of course :-)
Currently, this uses
Adam Lally wrote:
On 1/5/07, Marshall Schor [EMAIL PROTECTED] wrote:
After thinking harder about this - I'm concluding that users will need
to run a migration tool in any case to convert old JCas source classes
to the Apache form, and that tool can just as well do a conversion
Adam Lally wrote:
On 1/5/07, Marshall Schor [EMAIL PROTECTED] wrote:
Solution 1:
How about always passing in a JCasView object? For unaware components,
this would be the view to use. For view aware components, this would be
some view (perhaps picked in a similar way), but the user code would
Thilo Goetz wrote:
As I see it, we're not going to reach consensus on this issue. I
guess this is at least in part due to the fact that we disagree on the
basic premises underlying this redesign. I am -1 to the current
proposal, and I'll give my reasons below. However, I think we've
mostly
Thilo Goetz wrote:
snip I think it's useful to recognize there are sofa-aware
components, and sofa-unaware components. Most of the components so
far are sofa-unaware ones - although this may change somewhat over
time. I think it is useful to make writing sofa-unaware components
easy in
Thilo Goetz wrote:
snip I think the difficult UIMA developers find is not necessarily
an indication of the difficulty users would have. UIMA developers
are trying to keep multiple use cases of multiple kinds of users
(e.g. sofa-aware, sofa-unaware) in mind simultaneously, and come up
with a
Thilo Goetz wrote:
Sorry, I meant source distribution.
OK, I'm still not sure why this is needed? If folks want the source,
don't they get that from a tagged SVN level?
-Marshall
Thilo Goetz wrote:
Marshall Schor wrote:
Thilo Goetz wrote:
Sorry, I meant source distribution.
OK, I'm still not sure why this is needed? If folks want the source,
don't they get that from a tagged SVN level?
-Marshall
Apache projects always do a source distribution. As I understand
Sounds fine to me. -Marshall
Adam Lally wrote:
This has been stewing for a long time, so it's time to get it out in
the open here.
Users have difficulty figuring out how to use FeatureStructures that
are not derived from annotations (and not intended to just be
subordinate objects referenced
+1 from me.
-Marshall
Adam Lally wrote:
Even if we don't do the larger view redesign, I still think it makes
sense to drop TCAS:
http://issues.apache.org/jira/browse/UIMA-115
There is little reason for TCAS to still exist at this point - it no
longer defines any methods that are not on CAS,
Adam Lally wrote:
I added the Maven assembly descriptor for the source distribution.
There is one issue. I didn't include uima-docbooks, so with the
resulting source distribution you can build the jars/plugins but you
can't build the actual binary distribution (if you run mvn
assembly:assembly
Adam Lally wrote:
Also... is uima-docbooks/Source_UIMA_SDK_Guide_Ref needed for anything
or should we delete it from SVN?
This is the original xhtml sources from which we derived the docbook
sources.
It should not be in the distribution.
I think it can be deleted, but I would like to do
Adam Lally wrote:
On 1/8/07, Marshall Schor [EMAIL PROTECTED] wrote:
Here's a short proposal / straw-person that might address many of the
concerns raised.
1) Drop the JCas interface - only have the CAS interface. (one less
interface; process(...) method doesn't need variants depending
Thilo Goetz wrote:
Adam Lally wrote:
On 1/8/07, Thilo Goetz [EMAIL PROTECTED] wrote:
I see two reasonable alternatives. Neither involves a CommonCas.
a) The JCas assumes its wrapper nature. It implements its additional
functionality, and for all base functions, users refer to the CAS.
b)
Thilo Goetz wrote:
Marshall Schor wrote:
Thilo Goetz wrote:
I think there is sufficient resistance to the CommonCas, and we
should undo the change. Marshall?
I don't think it would be good to undo this. It seems valuable to me
to factor out common things, make more explicit what's
Thilo Goetz (JIRA) wrote:
[
https://issues.apache.org/jira/browse/UIMA-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thilo Goetz closed UIMA-25.
---
Resolution: Fixed
I've removed the comment and the corresponding code. The core
Thilo Goetz wrote:
Adam Lally wrote:
On 1/9/07, Marshall Schor [EMAIL PROTECTED] wrote:
Good point. It's very easy to obtain the DocBook build environment -
just go to our SVN repository and extract the uima-docbooks project.
I think I agree we don't need to distribute this at all; just
I'll add a test case for this. It should pass with the code as is, but
fail if the strange piece of code Thilo took out before is taken out again.
The test will be put in src/test/java/
org.apache.uima.cas.test.TypeSystemTest, in the method testArrayTypes().
You can see the last line now
Adam Lally wrote:
I just noticed that in uimaj-tools/src/main there is a directory named
org.apache.uima.tools.jcasgen. (That isn't Java package name
notation, the dots are actually in the diretory name.) Inside there
are .javajet files. Is this naming intentional? The dots confuse me
into
Thilo Goetz wrote:
Are you going to create (pointers to) the appropriate readmes for our
distribution?
I'm happy to help; can you say a bit more what is needed here?
-Marshall
Thilo Goetz wrote:
snip
I don't think we reported in October. We have one more month to do
before we go to the 3-month schedule.
Right you are.
Since the status page is supposed to have (links to) the statuses, I
recommend we put this on our web site. We'll still need to do a
cut/paste
Thilo Goetz wrote:
The link appears in the wrong place. Who can fix this?
--Thilo
We all can, I'm set up already to do it, so I'll do it.
-Marshall
Thilo Goetz wrote:
Can you elaborate? Is the website in SVN? Where? Is it generated,
is it html? Are there instructions on how to modify it somewhere?
All the info is reachable from here:
goto incubator.apache.org, in left side, under Podling Guides, click
on Podling PMC (PPMC),
I copied the status report to the board for January from the website to
the incubator wiki, reformatting it for wiki presentation.
If anyone changes it, please change in both places (unless and until we
get some automation here :-) )
-Marshall
Adam Lally wrote:
snip
Yes, I could add a new variant of CasCreationUtils.mergeTypeSystems:
public static TypeSystemDescription mergeTypeSystems(Collection
aTypeSystems,
ResourceManager aResourceManager, Collection
aOutputMergedTypeNames) throws ResourceInitializationException {
Thilo Goetz (JIRA) wrote:
snip I noticed that in the JCas, getAnnotationIndex() is on the the index
repository, not on the JCas. That seems reasonable, but is inconsistent with the
poCAS.
I think it should also be on the JCas, forwarding to the CAS. Any
objection to my adding it?
Adam Lally wrote:
Pushed send a little too quick... I also had another point to make.
Currently getNextIndex() does something strange - it queries the
current Java stack trace to figure out which cover class called it, so
that it knows which index is assigned to which class. This was added
Running Findbugs, etc., will report on throws / catches that are never
used because the code in the try doesn't throw what is being caught or
propagated up.
It might be good to clean these up. Typically, they are not changed,
because that kind of a change in an API breaks user code. I'm
We're changing a reasonable amount of stuff for 2.1. I think we might
need a migration guide. This could be both a chapter in the docbooks
and also a page on our website.
Opinions? Contributions?
Also, as changes are made to the code, please also update the relevant
docbook sources to
Thilo Goetz wrote:
snip
Err, IBM Java 5, now you mention it, I'm not sure I ever fixed that.
Let me check...
It's still broken - issue is some test depends on ordering of items
gotten from a hashmap. It's broken when running with IBM Java 5.0.
Works with Sun 5.0 according to Adam
I borrowed a Mac to do some testing. Setup Eclipse 3.2.1, with EMF and
Subclipse SVN client.
Checked out the code, installed maven 2
Did the maven setup for eclipse, etc.
The build almost worked, but got one test failure. Building with the
tests bypassed completed with no apparent error.
I tried changing the build scripts on the Mac, so the directory and
outputDirectory entries are ./ instead of /. That at least made the
ep-plugins have all the files.
However, the jars are not being built correctly - they're there, but
they're empty...
Anyone have any ideas how to fix
errors are
happening.
I did a chmod to make the jars have
-rw-r--r--
and then, the CDE actually started :-) Time to go to sleep, now... But
I'll enter a Jira issue to fix the maven build on Unix and Mac platforms.
-Marshall
Marshall Schor wrote:
I tried changing the build scripts
Thilo Goetz (JIRA) wrote:
CDE: adding feature value type in default namespace does not work correctly
snip
When adding a feature in the type system editor, try choosing a type in the
default (i.e., empty) namespace. The type will be added with a leading period.
Seems like the code does not
A user posted a forum question on
http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=444thread=145870cat=28
.
That link has a trail of discussion that led to a resolution - the
failing case involved the
PEAR including in its lib/ subdirectory some UIMA framework Jars, such
as
Mirko Jahn wrote:
snip Unfortunately do I get 5 errors in
the tests. I tried to find the source of the error, but the output of the
test was to big and even a dump of the output in a text file didn't
help me,
because it is more than 3 MB big and hard to search without RegEx
support in
the
In our Maven use, many times (for a new installation) Maven will fetch
Jars from a central Maven repository.
When running builds, Maven will query the central Maven repository to
see if more recent versions of a Jar are available, and if found, will
download them.
This page
//eclipse-ui-3.0.0/.jar/|
will be mapped to
|MAVEN_REPO/eclipse//java-sources//eclipse-ui-3.0.0/-sources.jar/|
-Marshall
Marshall Schor wrote:
In our Maven use, many times (for a new installation) Maven will fetch
Jars from a central Maven repository.
When running builds, Maven will query
Adam Lally wrote:
snip
My general opinion is - warn developers on possible conflicts, but
let them
go their own way.
1) I believe, PEAR Packager may post a warning that adding UIMA JARs to
a PEAR package may lead to conflicts, but it should not prevent
developers
from doing this, because we
Eddie Epstein (JIRA) wrote:
[
https://issues.apache.org/jira/browse/UIMA-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eddie Epstein resolved UIMA-187.
I see this API was added to the CAS, but was not added to the JCas. Is
1 - 100 of 2550 matches
Mail list logo
