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 packa
On 12/19/06, Jörn Kottmann <[EMAIL PROTECTED]> wrote:
I am not able to reproduce these exceptions. I have even downloaded
the package from sourceforge.
This occurs if something with the workspace is wrong. Maybe it helps
to "refresh" the project in the
navigator view.
Yes, that seemed to do it
When I run the tae.exe and select the sample-workspace, I see an error
in the "Corpus Explorer" view:
java.lang.NullPointerException
at net.sf.tae.ui.corpusview.CorpusExplorerView.createPartControl
(CorpusExplorerView.java:91)
at org.eclipse.ui.internal.ViewReference.createPartHelper
(ViewRefe
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
net.sf.tae.ui.c
On 12/19/06, Michael Baessler <[EMAIL PROTECTED]> wrote:
I did the changes described above and checked in the changes to SVN ...
everything works fine again in my eclipse workspace and only test fails
with the Maven build.
I will check that during the next days. If anyone has problems with some
t
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 su
[ http://issues.apache.org/jira/browse/UIMA-130?page=all ]
Adam Lally closed UIMA-130.
---
Resolution: Fixed
> ResourceCreationSpecifier.validate() provides no way to pass datapath
> information
> -
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
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
[ http://issues.apache.org/jira/browse/UIMA-130?page=all ]
Adam Lally reassigned UIMA-130:
---
Assignee: Adam Lally
> ResourceCreationSpecifier.validate() provides no way to pass datapath
> information
> --
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
Hi Thilo,
we (Lev, Yurdaer and me) thought about submitting something concerning
UIMA and OSGi, but the exact topic is not set right now. I think it
would be a big plus to coordinate possible submissions, to avoid
unnecessary duplications or even better provide a real story (like
talks w/o demo,
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
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 compa
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
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 (e
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: Transpor
[ http://issues.apache.org/jira/browse/UIMA-45?page=all ]
Michael Baessler reassigned UIMA-45:
Assignee: Michael Baessler
> Review and clean up unit tests
> --
>
> Key: UIMA-45
> URL: http:/
On 12/18/06, Marshall Schor (JIRA) 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 flag.
+1 to removing this
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/A&B is
created.
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 Wik
Jörn Kottmann wrote:
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 action a
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 keep
Marshall Schor wrote:
+1 from me, too. I would include running "RAT" as part of the process.
http://code.google.com/p/arat/
-Marshall
Absolutely. My plan is to get UIMA RAT-ready till the end of the year,
or at least have a very clear idea what issues remain. I expect that
most people wil
+1 from me, too. I would include running "RAT" as part of the process.
http://code.google.com/p/arat/
-Marshall
Michael Baessler wrote:
Thilo Goetz wrote:
I have added a short page on a release plan to the Wiki. I'm sure
this isn't the final word, and we'll keep refining it as we go.
Gi
Jörn Kottmann wrote:
...
> The new release is out now. I suggest to to take a look at the sample
> workspace.
...
Hi Joern,
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 nee
Thilo Goetz wrote:
I have added a short page on a release plan to the Wiki. I'm sure
this isn't the final word, and we'll keep refining it as we go.
Given this is our first release in the Incubator, and from what I've
been observing on [EMAIL PROTECTED], I think we should calculate
about 2 w
I'm planning to submit something on UIMA to ApacheCon Europe. I haven't
really thought much about it, other than that I want to go ;-) Anybody
else going to submit anything? Should we coordinate?
--Thilo
I have added a short page on a release plan to the Wiki. I'm sure this
isn't the final word, and we'll keep refining it as we go.
Given this is our first release in the Incubator, and from what I've
been observing on [EMAIL PROTECTED], I think we should calculate
about 2 weeks for the voting
29 matches
Mail list logo
