thanks, I'll take a look over the holidays. Sorry if things seems
a bit slow here right now, blame it on the approaching
holidays ;-) Here are a couple of things we need to take care of
for your code to be able to move to Apache.
I assume/hope you will want to move with your code and
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
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
Send Sofa mappings to remove services in process call
-
Key: UIMA-131
URL: http://issues.apache.org/jira/browse/UIMA-131
Project: UIMA
Issue Type: Improvement
Components:
Adam Lally wrote:
...
I'm a little less sure about the plan (on the Wiki) to have a minor
release (2.2, 2.3) about every 3 months, without knowing what
enhancements we want to get in. I could see releasing something about
every 3 months, if in some cases it would just be a maintenance
release
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/15/06, Michael Baessler [EMAIL PROTECTED] wrote:
So my suggestion is to
keep the
uimaj-test-util project but fix and redesign some of the methods to use
class loading to find resources. For example replace the
JUnitExtension.getFile() method with the code below to load the
resources using
Provide better support for filenames with spaces in resource URL
Key: UIMA-132
URL: http://issues.apache.org/jira/browse/UIMA-132
Project: UIMA
Issue Type: Improvement
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
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
15 matches
Mail list logo
