,
Antoine
Original-Nachricht
Datum: Mon, 6 Nov 2006 10:46:54 -0500
Von: Adam Lally [EMAIL PROTECTED]
An: repository@apache.org
Betreff: Can/should eclipse jars go in m2-snapshot-repository
Hi,
I'm looking for some advice here... I'm just getting started working
within Apache
Since there's no JIRA yet issues get logged to the dev list. :)
I'm getting two failures running the tests under Sun Java 1.5.
One failure is a test that uses xi:include, which doesn't work in Java
1.5. I removed most of those from our tests but a couple are left.
Is it time to just remove
One failure is a test that uses xi:include, which doesn't work in Java
1.5. I removed most of those from our tests but a couple are left.
Is it time to just remove this feature entirely? In addition to not
working in Java 1.5 (unless you separately install xalan.jar), it's
also not supported in
On 11/7/06, Michael Baessler [EMAIL PROTECTED] wrote:
+1 from my side, I also think that we can drop xi:include.
- Michael
I should probably clarify that my patch doesn't remove xi:include
support for UIMA; it only modifies the testcase to use import instead.
The actual removal can be done
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 agree with that meaning of SDK, but seem to have come to the
opposite conclusion. :) What I was proposing as
On 11/9/06, Marshall Schor [EMAIL PROTECTED] wrote:
snip/
So branching and tagging aren't very straightforward in that scenario.
I'm not sure this is true. Yes, creating a branch or tag is copying the
whole project, but it is a lazy copy. So, yes, it would collect a bunch of
things that
On 11/14/06, Marshall Schor [EMAIL PROTECTED] wrote:
I like the idea of a category for these. It looks like we cannot add
categories?
It would be nice if there were an additional column we could use to
select these out.
snip/
What do these really have in common that merits a category?
On 11/15/06, Thilo Goetz [EMAIL PROTECTED] wrote:
- When setting up the build for Eclipse, the M2_REPO variable needs to
be set up manually. Is this correct? If so, this is missing from the
instructions, and I'll be happy to add the information.
The M2_REPO variable should be created by this
On 11/15/06, Marshall Schor [EMAIL PROTECTED] wrote:
We should obviously remove IBM from this. But what do you think we
should use?
C:/Program Files/uima
C:/Program Files/apache/uima
C:/Program Files/apache-uima
C:/uima
C:/apache/uima
C:/apache-uima
Other?
I like the 3rd one. It
Not sure I follow you. I admit that the ignore whitespace option is
less than perfect (it can't seem to handle newlines correctly, which is
a pain).
Yes, even with ignore whitespace set, the Eclipse compare shows every
change in line wrapping that was caused by your reformat. The Java
On 11/16/06, Marshall Schor [EMAIL PROTECTED] wrote:
The docs describe collection readers and cas initializers. The latter
is deprecated - so I'm removing it from the docs.
Complex collection readers are do-able using re-usable AE parts. What
else should I be saying in the docs about this?
Are
I fixed a bug (reported on the forum) that the Annotation Viewer
didn't support the new primitive types. But I'm not so happy with my
fix... it involved a lot of if..else if blocks for each of the
different array types. You can get an idea of how ugly it was to
implement this just by scanning
I was going to answer you can use LowLevelCAS.ll_getTypeClass(int
typeCode) but I see that Bhavani failed to update that method for the
new types. I will have to deal with the same thing in the CVD one of
these days. When I do, I'll go back to the annotation viewer and see if
I can straighten
On 11/17/06, Michael Baessler [EMAIL PROTECTED] wrote:
snip/
so I would recommend that
we just rename the IBMResultPrinter class to ResultPrinter. I will take
care of that if all agree.
Fine with me.
While you're in there you might also want to take a look at what I did
to TestPropertyReader
On 11/17/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Is this something you would like to see fixed in the TypeSystemMgr, or
in the code that calls the TypeSystemMgr? I believe I can probably fix
it in the TypeSystemMgr without too much work.
I already committed the fix for it in the code that
And the winners are...
Braces: {
Looks like I'm outvoted on this one.
}
Indentation: 2 spaces. No tabs!
Member Variables: before methods
Line Length: 100 (Preferred indent after wrapping: 8 spces)
Imports: do not use package imports (e.g. import org.uima.*). order
imports alphabetically
Please review.
Now if only our code conformed to our conventions. :)
Also, I liked Thilo's idea of saying something about compiler warning
settings and/or FindBugs rules. I'll let Thilo drive the proposal on
that if he wants to.
-Adam
Are there Eclipse configuration options necessary to meet any of these
winners?
One step ahead of you. See our podling web site. :)
-Adam
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).
I entered version 2.1 into JIRA and assigned a bunch of issues to it
(all the ones listed on todo.html plus others I
They're linked off the home page.
Instructions on how to update them posted on the Wiki:
http://cwiki.apache.org/confluence/display/UIMA/Instructions+for+Committers
-Adam
On 11/16/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Adam Lally wrote:
I fixed a bug (reported on the forum) that the Annotation Viewer
didn't support the new primitive types. But I'm not so happy with my
fix... it involved a lot of if..else if blocks for each of the
different array types
I'd like to post JavaDocs for all our source code on our website.
I've got the Maven javadoc build working, though I want to organize it
a little better.
I think we don't want these JavaDocs in SVN for uima-website. (I
found one thread in the incubator-general archives indicating that
this is
On 11/21/06, Marshall Schor [EMAIL PROTECTED] wrote:
I'm changing JTextAnnotator_ImplBase to JCasAnnotator_ImplBase, because
of the Javadoc comments
indicating that JTextAnnotator_ImplBase is now outmoded (still works -
for backwards
compatibility, but new stuff should use the new approach).
On 11/21/06, Marshall Schor [EMAIL PROTECTED] wrote:
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
On 11/19/06, Thilo Goetz [EMAIL PROTECTED] wrote:
I have posted our proposal here:
http://cwiki.apache.org/confluence/display/UIMA/Eclipse+Compiler+Settings
If you turn these on, the UIMA source code lights up like a Christmas
tree ;-)
I spent about an hour trying to fix warnings in
When cleaning out warnings I did find a couple of things worth
exploring further:
1) LinearTypeOrderBuilderImpl: a couple of parameters hide fields.
This could be just a case where the parameter should be renamed, but I
wasn't entirely sure if some other cleanup was warranted, so I left
it.
2)
I spent about an hour trying to fix warnings in uimaj-core. I'm now
not so happy with having the following warnings turned on:
Another one I turned off: Unnecessary definition of thrown checked
exception. This is another warning that flags public/protected
methods intended to be overridden
The original name was TafAnalysisComponent, but Component accidentally became
Engine during the renaming of Taf to UimaCpp.
Oops, sorry about that. I thought I had a lot of Engine things after
I was done with the renaming ;-)
No problem. Good thing the file also had compile warnings in
It looks like there's only one reference, from the test cases, and
that could be replaced.
-Adam
On 11/25/06, Marshall Schor [EMAIL PROTECTED] wrote:
I need to write up the version 2 tutorial and user's guide for Results
Specification. The current write up is inaccurate, I think. I started
to change it to fit the new API where it is not passed in as a
parameter, but there are more things
On 11/24/06, Thilo Goetz [EMAIL PROTECTED] wrote:
I'll volunteer to be the release manager for the first release
+1
-Adam
I realized that the indent after line-wrapping setting was wrong in
the Eclipse code style preferences file that I posted. I set it to
8, thinking that meant 8 spaces, but it looks like it was actually
interpreted as 8x the normal indent, so 16 spaces. That's way too
much and caused some really
Hi Matthias,
To subscribe to the uima-dev list, please send mail to
[EMAIL PROTECTED]
Regards,
-Adam
On 29 Nov 2006 12:46:33 -,
[EMAIL PROTECTED]
[EMAIL PROTECTED]
wrote:
To approve:
[EMAIL PROTECTED]
To reject:
[EMAIL PROTECTED]
To give a reason to reject:
%%% Start comment
%%% End
On 11/29/06, Marshall Schor [EMAIL PROTECTED] wrote:
The big doc says in the section on how to deploy a UIMA component as a
Vinci service to use a deployment descriptor which contains
parameter name=serializerClassName
value=...service.vinci.VinciXCASSerializer_NoDocText/
Actually I just
On 11/29/06, Marshall Schor [EMAIL PROTECTED] wrote:
The big doc says UIMA automatically detects if JMX is available. I
changed this to specify that the detection is if JMX is available in the
JVM (it could be Java 5, or Java 1.4 with the JMX reference impl from
Sun downloaded). Is this
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 break compatibility with previous versions:
http://cwiki.apache.org/UIMA/noncompatiblechanges.html
-Adam
On 11/30/06, Marshall Schor [EMAIL PROTECTED] wrote:
Seems this content might be combinable with existing page: Documentation
- Differences between Version 2 and Version 1?
Good point, I've merged it with that page now. But how do I delete
the old page? I went to the page (reachable from the
On 12/7/06, Marshall Schor [EMAIL PROTECTED] wrote:
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
On 12/7/06, Marshall Schor [EMAIL PROTECTED] wrote:
snip/
After several hours of unsuccessful looking for why, I'm giving up (for
now) and saying you have to use Java 5 or some 1.4.2 Java (not IBM's)
that recognizes xercesImpl, to build docbook.
I got Sun JDK 1.4.2 to work. However it
On 12/8/06, Lev Kozakov [EMAIL PROTECTED] wrote:
Unfortunately, the problem is more complicated that I thought at the
beginning.
snip/
Let me try to simplify. I'll propose a solution and you can tell me
why it wouldn't work.
1) When PearInstaller launches the JVM for CVD, it will set its
On 12/8/06, Lev Kozakov [EMAIL PROTECTED] wrote:
1) When PearInstaller launches the JVM for CVD, it will set its
classpath to the contents of the java.class.path system property of
the PearInstaller's own JVM. Thus CVD will run with the same
classpath as PearInstaller. Since CVD is in the
On 12/8/06, Lev Kozakov [EMAIL PROTECTED] wrote:
Actually, I already started modifying the code, so now I need to review
your changes and, may be, add more.
OK. Your last email sounded like you weren't going to work on this.
Just a minute ago I checked in the changes to allow the help file
On 12/8/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Yes, a single line inserted after process(inCas,...):
inCas = inCas.getView(); // automatically added by migration
I suppose that should work. It might be a bit ugly for multi-Sofa
annotators who expect inCas to refer to the Base CAS.
On 12/11/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Also, I think it's premature to look to the OASIS work for guidance.
Let's follow our own good sense until the standard is at a stage where
we feel confident it won't change much.
I think that depends on the situation. Certainly, I would not
(See https://issues.apache.org/jira/browse/UIMA-34)
In the Vinci service deployment descriptor there can be an element:
parameter name=timeoutPeriod value=3/
This is supposed to be used when there are more concurrent requests
on the service than
there AnalysisEngine instances to handle
On 12/11/06, Thilo Goetz [EMAIL PROTECTED] wrote:
So what about Adam's suggestion to separate a CAS from a view? What
*is* the difference, conceptually?
A View has an index repository and a Sofa. (The Sofa may become
optional, but in the current impl. it is not.)
A CAS holds the analysis
On 12/11/06, Thilo Goetz [EMAIL PROTECTED] wrote:
The heap? How does that come into the picture?
I just meant that the CAS is where the actual data (the FeatureStructures) live.
What about the type system? Is that accessible from the CasView, or
just from the CAS?
Logically, the
On 12/11/06, Eddie Epstein [EMAIL PROTECTED] wrote:
The server rejecting a request after this timeout does not make sense to
me, as the client should decide how long to wait. On the other hand,
services that require lots of processing per request may not want to start
processing long-delayed
On 12/11/06, Eddie Epstein [EMAIL PROTECTED] wrote:
Sounds good. Maybe we should add a JIRA issue to remove any other code
hanging around that doesn't work?
:) That only works if the feature that doesn't work *is also
ill-conceived*... an important qualification. :)
-Adam
On 12/12/06, Eddie Epstein [EMAIL PROTECTED] wrote:
Currently the base CAS and views have the same API set, the only
differences between the base CAS and all other views are:
- the base CAS has no index repository
- the base CAS has no Sofa
Given a base CAS it is possible to create FS,
I put up a preliminary Wiki page highlighting areas where the Proposed
OASIS UIMA Specification currently deviates from what we've
implemented.
http://cwiki.apache.org/UIMA/architecturecomplianceissues.html
These aren't necesarily things we need to address any time soon, since
the OASIS UIMA
On 12/13/06, Michael Baessler [EMAIL PROTECTED] wrote:
- To package a analysis component as pear file we have to use eclipse,
since we do not have a pear packager outside of eclipse. So users have
to use eclipse if they want to package an analysis component.
Hmmm.. how hard would it be to have
On 12/13/06, Michael Baessler [EMAIL PROTECTED] wrote:
I thought the default PEAR directory layout was optional. It would be
nice if the Maven layout were supported.
I don't think the UIMA nature is optional. Some of the directories must
exist but maybe we can change that...
I think only
On 12/13/06, Lev Kozakov [EMAIL PROTECTED] wrote:
Sorry. I did not realize this CDATA section is a Docbook XML element. I
uploaded another patch with CDATA section restored. I also would like to
remove the old patch, but don't know how to do this.
Only people in the uima-developers JIRA group
On 12/13/06, Thilo Goetz [EMAIL PROTECTED] wrote:
I couldn't agree more (except for the default bag indexes). It makes no
sense at all that global indexes must be accessed via a particular view.
I can't tell what exactly you're agreeing to. Are you thinking that
anything indexed in a view
On 12/14/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Hi Joern,
is this your Text Analysis Environment on SourceForge
(https://sourceforge.net/projects/tae/)? Looks pretty cool! This would
be a nice addition to our Eclipse-based tooling.
--Thilo
I got this from SourceForge but was unable to
I've made some good progress on a utility that can be used to help
users migrate their code from IBM UIMA to Apache UIMA.
The class is org.apache.uima.tools.migration.IbmUimaToApacheUima in
uimaj-tools, and there are corresponding .bat/.sh scripts in
uimaj-distr.
It's basically just a glorified
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 sharing in some
On 12/19/06, Thilo Goetz [EMAIL PROTECTED] wrote:
now - 1/21/07:coding, general enhancements
1/22/07 - 2/4/07: testing bug fixing
2/5/07: cut the release, start the vote
2/15/07: release UIMA 2.1
+1 to this schedule.
I'm a little less sure about the plan (on the Wiki)
On 12/18/06, Marshall Schor (JIRA) uima-dev@incubator.apache.org wrote:
This flag, called -ae, if set false, generates a TAE as the output of the
merge operation. Is this functionality appropriate? Unless others chime in in the next couple of days to
the contrary, I suggest removing this
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 summary of the conclusions we reached.
Please comment.
Basic Ideas:
* The CAS is the container for all of the analysis data (as per the
This is a proposal for how to preserve some amount of backwards
compatibility if we do the CAS / CasView API redesign currently being
discussed. This only addresses single-Sofa annotators/applications,
but that is the vast majority of the code out there and so I'm willing
to accept breaking
On 12/18/06, Jörn Kottmann [EMAIL PROTECTED] wrote:
The new release is out now. I suggest to to take a look at the sample
workspace.
When I run the tae.exe and select the sample-workspace, I see an error
in the Corpus Explorer view:
java.lang.NullPointerException
at
On 12/19/06, Marshall Schor [EMAIL PROTECTED] wrote:
How about: We explicitly document that if feature extension is used with
JCas, you need to
(a) package type systems and the JCas generated classes
separately from other packagings, and
(b) be willing to re-run JCasGen when
your type package
On 12/21/06, Thilo Goetz [EMAIL PROTECTED] wrote:
I haven't thought this through yet, but here's how I see indexes and
their relation to views right now. Let me know if this agrees with your
views, or how it differs.
The index repository is a set of indexes, at least right now. All it
can do
On 12/21/06, Thilo Goetz [EMAIL PROTECTED] wrote:
The idea is that a CAS has a current view (best term I can think of
for it right now). Any methods on the CAS that are view-oriented will
apply to the current view. This includes but is not limited to:
getSofa()
getDocumentText()
A collection of quotes from Thilo about global indexes. After reading
all these I think I finally might be on the same wavelength... (we'll
see in a moment :)
On 12/22/06, Thilo Goetz [EMAIL PROTECTED] wrote:
snip/
Global indexes should be shared. That is
also the spirit of the OASIS draft,
On 12/22/06, Marshall Schor [EMAIL PROTECTED] wrote:
Re: What to do about Document Annotation for 2.1.
a) Do the work to make it easy to get singletons (or whatever we're
calling this feature) out of the CAS
b) Change JCasGen to not generate DocumentAnnotation if the merged
version = the base
if (featOkTst casFeat_ == null)
JCas.throwFeatMissing(, cas-type-name-for-);
These calls are in pre-existing JCas cover classes. I guess we're
planning to have new JCas cover classes generated
(unless we put in a layer to make the old ones work - they would be
tying
On 12/26/06, Marshall Schor [EMAIL PROTECTED] wrote:
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
On 12/26/06, Marshall Schor [EMAIL PROTECTED] wrote:
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 :-)
To me it looks like these were
On 12/27/06, Thilo Goetz [EMAIL PROTECTED] 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
On 12/27/06, Thilo Goetz [EMAIL PROTECTED] wrote:
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
More later (time to take stock of where we are again, I think...) but first:
On 12/27/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Adam Lally wrote:
On 12/22/06, Marshall Schor [EMAIL PROTECTED] wrote:
snip
Also, we have some uses of non-annotation indexes that are segregated
by Sofa (say
Yes, I'll fix those. The only ones I see are in AnalysisEngine.java.
Are there others I'm missing?
-Adam
On 12/28/06, Marshall Schor [EMAIL PROTECTED] wrote:
Adam - there are a bunch of comments in the code that look like:
@link #process(, ResultSpecification)
I think some of these
This chain of emails has a lot of tangled threads and this is an
attempt to disentangle them and reevaluate what it we're trying to
acheive.
I think there were basically two motivations for the whole ball of yarn:
(1) We're unhappy with some of our APIs, in particular (a) the
interface CAS can
On 12/28/06, Marshall Schor [EMAIL PROTECTED] wrote:
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
On 12/28/06, Marshall Schor [EMAIL PROTECTED] wrote:
Adam Lally (JIRA) wrote:
I still think that moving the static utility methods from JCasImpl to a new
JCasUtil class might be would be worthwhile. Also there's the trick that EMF
uses: you can't call a method JCas.method() where JCas
On 12/29/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Also, I don't feel like second-guessing the OASIS TC at this point. We
have nothing but the Research report to on right now, and every reason
to believe that it will change significantly before morphing into a
standard.
I'm not sure I get
Well, the concrete may not have quite set yet... but here goes:
1. Goals
The following are confusing (or some might say, broken)
(a) the interface CAS can be an interface to either the whole CAS or to a
view. Methods like this are poor:
CAS view = cas.getView(name);
(b) the logic
On 12/29/06, Thilo Goetz [EMAIL PROTECTED] wrote:
I didn't mean ignore; there isn't much to ignore right now ;-) I'm
waiting to jump on any technical discussion that might develop there,
but there is nothing. I don't have the bandwidth to initiate anything
myself. However, I'm certainly
On 12/29/06, Marshall Schor [EMAIL PROTECTED] wrote:
snip/
It seems to me you will need a CasViewImpl class - this is for the use
case where the user
wants to, e.g., run two iterators together, one iterating over one view,
while the other goes over
another view.
The actual objects that
On 12/30/06, Thilo Goetz [EMAIL PROTECTED] wrote:
So your proposal is to leave things as they are, except that we call
some of the things that we used to call a CAS a CasView. We're not
going to touch how indexing works, at least conceptually. We could
implement this proposal by simply making
On 12/30/06, Thilo Goetz [EMAIL PROTECTED] wrote:
Why use the bandwidth to design it here, rather than initiate it at
OASIS?
snip
Because things are happening here, and not at OASIS. If and when that
changes, we can take our discussion there. If you would like to start
some discussion at
On 1/2/07, Thilo Goetz [EMAIL PROTECTED] wrote:
snip/
I'm not sure there's a contradiction between what I'm proposing,
and what's in the spec proposal. When I run an Apache UIMA application,
I make the decision what I want to see in my CAS. Any other application
deserializing XMI files may do
On 1/2/07, Thilo Goetz [EMAIL PROTECTED] wrote:
I wouldn't mind doing this as a first step, but I'm concerned about the
future. If we need to support this approach going forward, I would
prefer if we could answer the questions about the relation between the
CAS and CasViews first: how are
On 1/2/07, Marshall Schor [EMAIL PROTECTED] wrote:
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.
This may be primarily for Eddie but others may wish to comment:
The following currently does not work in the CPE descriptor:
collectionReader
collectionIterator
descriptor
include
href=descriptors/collection_reader/FileSystemCollectionReader.xml/
On 1/2/07, Marshall Schor [EMAIL PROTECTED] wrote:
I think this proposal also has one set of index definitions, and each view
gets its own private set of index-instances for these definitions.
Correct.
Will the methods not really associated with a CAS object (they are or
could be
static
On 1/3/07, Marshall Schor [EMAIL PROTECTED] wrote:
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
I put up a Wiki page giving the suggested breakdown of methods between
the existing interfaces CommonCas, CAS, JCas and new interfaces
CommonCasView, CasView, and JCasView. Please take a look:
http://cwiki.apache.org/UIMA/casandcasviewinterfaceredesign.html.
-Adam
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 these to CommonCas,
On 1/4/07, Thilo Goetz [EMAIL PROTECTED] wrote:
Adam Lally wrote:
The process call would take a CAS. Inside the body of the process()
method there would be no issue, but I'm thinking about other methods
that the user has implemented that need access to the indexes and also
need to create
This note is really from Marshall. He's having email trouble so I
posted it on his behalf.
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
On 1/4/07, Marshall Schor [EMAIL PROTECTED] wrote:
- On the JCas interface, can we remove some of the APIs and just make
them available on the impl object? I'm thinking of things like
putJfsFromCaddr(int, FeatureStructure) and getType(int).
I think these may be called from JCas
On 1/4/07, Marshall Schor [EMAIL PROTECTED] wrote:
Adam Lally wrote:
FYI I made updates to the Wiki page - see my comments on the page for
details.
-Adam
I probably just missed it, but given a JCasView, how do get the
corresponding JCas?
Thanks for catching that omission. I have added
On 1/4/07, Marshall Schor [EMAIL PROTECTED] wrote:
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
On 1/4/07, Marshall Schor [EMAIL PROTECTED] wrote:
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
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.
Currently, this uses whichever view (meaning a JCas instance) was
passed to the constructor
On 1/4/07, Marshall Schor [EMAIL PROTECTED] wrote:
Adam Lally wrote:
So I think we need to deprecate addToIndexes().
Not sure about this - because the current view mechanism would
seem to make this work, even for multi-sofa. We could even put in
code that checked if the item being indexed
1 - 100 of 1020 matches
Mail list logo
