+1 to remove it, from me, but Thilo could take a look too...
I commented it out to test removing it, and didn't see any compile
errors. (didn't commit)
-Marshall
Jörn Kottmann wrote:
> Hi,
>
> the class has private constructor which is never used.
> Is there a reason for it ?
>
> Otherwise I wou
+1 -Marshall
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> +1 to remove it, from me, but Thilo could take a look too...
>>
>> I commented it out to test removing it, and didn't see any compile
>> errors. (didn't commit)
>>
> Actually I starte
we list that jar in the POM as a dependency, if someone has put that
jar into the maven repo?
- Marshall
>
> Jörn
>
> On Jul 4, 2009, at 8:19 PM, Marshall Schor wrote:
>
>> left-over thing: in the repository spec for "CentralEclipse" - I had
>> temporarily c
The exception you encountered occurs when an ant script tries to execute
In your case the message indicates that ${tmp.dir}/fop.zip is
/Users/bouba/Documents/workspace_uima/PearPackagingMavenPlugin/target/temp/fop.zip
The message about a "negative seek" would seem to be caused by some corru
Baptiste Gaillard wrote:
>
>
>
>
>
> Hi,
>
> I'm trying to compile the last version of the PearPackagingMavenPlugin, but
> it seems there is a problem on PDF generation...
>
> Here is the exception I've encountered:
> [ERROR] BUILD ERROR
> [INFO]
> -
The POM for this specifies
org.apache.uima
PearPackagingMavenPlugin
2.2.2-incubating
provided
Because I blew away my local maven repo at some point and rebuilt it -
it rebuilt with version 2.3.0-incubating-SANDBOX
There are lots o
Thilo Goetz wrote:
> Hi all,
>
> I was trying to build the sandbox today and noticed several
> issues (see also Marshall's earlier note).
>
> 1. The sandbox build is not documented, or at least I
> couldn't find anything. There's a short bit under
> "creating a distribution", but there's nothing
While doing some generics work in uimaj-core, I came across the hashCode
impl in this class; it has one possible problem in that it uses Math.abs
in an attempt to return just non-negative ints. This is required in
other places, where the hash code is used to create indexes using
hashCode % some-si
When adding generic type info to UIMA core, if there is a method which
is declared to return a List, and we change it to return a
List, and the method is part of the UIMA public API - does
that "break" the public API? Or will code that is already written to
use it continue to work? I think the co
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> Hi all,
>>>
>>> I was trying to build the sandbox today and noticed several
>>> issues (see also Marshall's earlier note).
>>>
>>> 1.
no objections - sounds good. +1 to graduate it from sandbox and publish
to incubator repo. in next release.
-Marshall
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Thilo Goetz wrote:
>>
>>> - the pear packaging maven plugin project must be built first
>>> and manually if it's not in t
ist|", you will be locked
into that decision
This is because it's binary compatible to go from --no generic info-- to
some-generic-info, but it is not binary compatible to change the
generic-info once it is there.
-Marshall
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> Is this
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> When adding generic type info to UIMA core, if there is a method which
>> is declared to return a List, and we change it to return a
>> List, and the method is part of the UIMA public API - does
>> that "break"
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> Jörn Kottmann wrote:
>>
>>> Marshall Schor wrote:
>>>
>>>> When adding generic type info to UIMA core, if there is a method which
>>>> is declared to return a List, and we change it
Marshall Schor wrote:
> Jörn Kottmann wrote:
>
>> Marshall Schor wrote:
>>
>>> Jörn Kottmann wrote:
>>>
>>>
>>>> Marshall Schor wrote:
>>>>
>>>>
>>>>> When adding gener
I think this fix gives rise to another test case failure. I backed out
this fix, and the (I think new) test in IteratorTest - testIterator
fails on line 357.
With this fix restored, there is a failure on IteratorTest - testDelete,
line 662.
Thilo - I think you are the best person to investigate
ion "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)
-Marshall
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> I think this fix gives rise to another test case failure. I backed out
>>
Just FYI - On my setup & system, it fails both in mvn and Eclipse.
Note that I started with a brand new extract of SVN done on Saturday.
Looking forward to unraveling this mystery :-) -Marshall
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Interesting...
>>
>&
mented better. And
what if no sorting order was defined for the set index?
-Marshall
Marshall Schor wrote:
> I think this fix gives rise to another test case failure. I backed out
> this fix, and the (I think new) test in IteratorTest - testIterator
> fails on line 357.
>
&
Thilo Goetz wrote:
> See the Jira issue for the cause of the problem. More
> comments below.
>
> Marshall Schor wrote:
>
>> So, there may be 2 things to look at here - the actual error, described
>> above, and the more philosophical question on the behavior o
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> See the Jira issue for the cause of the problem. More
>>> comments below.
>>>
>>> Marshall Schor wrote:
>>>
>>>
>>>>
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> Marshall Schor wrote:
>>>
>>>
>>>> Thilo Goetz wrote:
>>>>
>>>>
>>>>> See the Jira
4, 2009, at 10:42 PM, Marshall Schor wrote:
>
>>
>>
>> Jörn Kottmann wrote:
>>> Marshall Schor wrote:
>>>> Jörn Kottmann wrote:
>>>>
>>>>> Marshall Schor wrote:
>>>>>
>>>>>> When adding generic t
+1 -Marshall
Thilo Goetz (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735944#action_12735944
> ]
>
> Thilo Goetz commented on UIMA-1257:
> ---
>
>
Let's get a list of sandbox projects we plan to include in the
2.3.0-incubating release.
The reason for doing this is to better update the version info for the
sandbox. For uimaj we use maven properties and have the version info in
just one place for all the projects. We could do that too, for
Marshall Schor wrote:
> Let's get a list of sandbox projects we plan to include in the
> 2.3.0-incubating release.
>
> The reason for doing this is to better update the version info for the
> sandbox. For uimaj we use maven properties and have the version info in
> jus
While fixing up the sandbox build I ran across what looks like a bug -
the PearAnalysisEngineWrapper is throwing a NPE because it is being
passed in "null" for the map of additional parameters in its
"initialize" method, and it's not expecting that.
Here's one such path where null is passed in:
U
ues in the
PearAnalysisEngineWrapper
-Marshall
Marshall Schor wrote:
> While fixing up the sandbox build I ran across what looks like a bug -
> the PearAnalysisEngineWrapper is throwing a NPE because it is being
> passed in "null" for the map of additional parameters in its
> "initialize
I can see Michael's point to have sandbox things depend on released
components, but only for those sandbox things not being released.
When we get to release time, for the ones being released, the released
components (if it follows all of our other conventions, and maven
conventions) in the tag wil
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Let's get a list of sandbox projects we plan to include in the
>> 2.3.0-incubating release.
>>
>> The reason for doing this is to better update the version info for the
>> sandbox. For uimaj we use mave
Some of our sandbox project include jars such as jsr173_1.0_api, in a
lib/ directory, as part of our distribution.
Some of our projects indicate, for included jars like this, what the
license is, in the NOTICE file (e.g. the RegularExpressionAnnotator).
Others are silent (e.g. the SimpleServer).
: UIMA-1465
>> URL: https://issues.apache.org/jira/browse/UIMA-1465
>> Project: UIMA
>> Issue Type: Bug
>> Components: Core Java Framework
>>Affects Versions: 2.2.2
>>Reporter: Marshall Schor
>>
if we're doing the same thing, then it should have been failing
for your situations. Do you have a sample / test case or whatever I
could try? I'll back out the change and test why it *isn't* failing.
That should shed some light on my understanding in this area :-)
-Marshall
&g
It's been left open. Should this be closed? -Marshall
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> It's probably not important, but I don't understand what the
>>> difference is between "creating a top level pearSpecifier kind
>>> of AE" (your wo
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> Marshall Schor wrote:
>>>
>>>
>>>> Thilo Goetz wrote:
>>>>
>>>>
>>>>> It's prob
I would like to propose graduating UIMA-AS from the sandbox, making it a
separately downloadable "add-on" to base UIMA. It has been extensively
used in several projects and has undergone (as a result) a lot of
bug-fixing and hardening. With the upcoming release, I think it would
make sense to grad
The vote has been open for about a week, and we have
+1 Marshall Schor
+1 Eddie Epstein
+1 Jaroslaw Cwiklik
+1 Tong Fin
+1 Jochen Leidner
+1 Jörn Kottman
+1 Thommaso Teofili
+1 Burn Lewis
+1 Adam Lally
There were no 0 or -1 votes.
The vote passes.
Thanks to everyone for voting!
-Marshall
Thilo Goetz wrote:
> Eddie Epstein wrote:
>
>> Let's pick a date for a first release candidate, say August 28,
>> and get different people to take responsibility for various packages
>> to be ready. Then we do a status check on that date to see what
>> goes forward?
>>
>
> I'm sorry to say
I plan to move uima-as out of the sandbox sometime this weekend.
Those of you who may have it checked out will need to "switch" your
checked-out version to the new position.
Here are the details:
Current (old) position:
... incubator
uima
sandbox
trunk
uima-as
e/UIMA-1479
>> Project: UIMA
>> Issue Type: Task
>> Components: Async Scaleout
>>Reporter: Marshall Schor
>>Assignee: Marshall Schor
>>
>> UIMA-AS was voted to graduate from the sandbox. Make the need
Jörn Kottmann (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740135#action_12740135
> ]
>
> Jörn Kottmann commented on UIMA-1479:
> -
>
> I woul
Hi Rico - thanks for the reminder :-) I'll add it... -Marshall
Rico Landefeld wrote:
> hi there,
>
> Lucas should be part of the upcomming 2.3.0 release.
>
> rico
>
>
> On Thu, Jul 30, 2009 at 12:56 AM, Tong Fin wrote:
>
Is the SimpleUimaAsService ready for prime time? I don't
recal
Thilo Goetz wrote:
> Thilo Goetz wrote:
>
>> Marshall Schor wrote:
>>
>>> Thilo Goetz wrote:
>>>
>>>> Marshall Schor wrote:
>>>>
>>>>
>>>>> Thilo Goetz wrote:
>>>>&g
AnnotationIndex interface extends
FSIndex extends
Iterable.
Iterable interface defines one method,
iterator where T is AnnotationFS (in this case).
AnnotationIndexImpl implements AnnotationIndex.
Therefore, it has a method, iterator, whose return value is
FSIterator.
---
The hi
A user had written this:
public static Iterator annotationsIterator(
JCas aJCas, int type) {
return aJCas.getAnnotationIndex(type).iterator(); // fails, cannot
convert from FSIterator to Iterator
}
This compile-time error can be eliminated by changing the generification
of Annotat
Jörn Kottmann wrote:
>
>> The current choice in generification doesn't support this; a fix would
>> be to change AnnotationIndex generification from
>> public interface AnnotationIndex extends FSIndex to
>> public interface AnnotationIndex extends FSIndex
>>
>> Is this correct?
>>
> The reas
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> A user had written this:
>>
>> public static Iterator annotationsIterator(
>> JCas aJCas, int type) {
>> return aJCas.getAnnotationIndex(type).iterator(); // fails, cannot
>> convert from F
The createFilteredIterator method in CASImpl takes an FSIterator and an
FSMatchConstraint, and returns another iterator.
The generification of this is:
public FSIterator
createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
return new FilteredIterator(it, cons);}
This means that t
getViewIterator in CASImpl is written with the signature:
Iterator getViewIterator()
If you are working with things needing CASImpl objects, you would write:
Iterator s = aCas.getViewIterator();
while (s.hasNext()) {
CASImpl ci = (CASImpl) s.next();
... code using ci...
}
If we
I'd like to freeze in 3 weeks, if that is reasonable. For all of you
with code that you want to have in the release, is 3 weeks (Aug 28 - a
Friday) too soon to freeze (stop developing, and see if we can cut a
release candidate)?
This means:
coding of any new things is done, tests written, and e
Jörn Kottmann wrote:
>
> On Aug 7, 2009, at 8:57 PM, Marshall Schor wrote:
>
>> getViewIterator in CASImpl is written with the signature:
>> Iterator getViewIterator()
>>
>> If you are working with things needing CASImpl objects, you would write:
>>
Jukka Zitting wrote:
> Hi,
>
> On Fri, Aug 7, 2009 at 8:57 PM, Marshall Schor wrote:
>
>> Would it be better to have that form of the signature?
>>
>
> I don't know much about UIMA patterns, but in general something like
> that seems a bit questiona
Adam Lally wrote:
> On Sat, Aug 8, 2009 at 4:57 PM, Marshall Schor wrote:
>
>> Jörn Kottmann wrote:
>>
>>> On Aug 7, 2009, at 8:57 PM, Marshall Schor wrote:
>>>
>>>
>>>> getViewIterator in CASImpl is written with the signatu
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> Adam Lally wrote:
>>
>>> On Sat, Aug 8, 2009 at 4:57 PM, Marshall Schor wrote:
>>>
>>>> Jörn Kottmann wrote:
>>>>
>>>>> On Aug 7, 2009, at 8:57 PM, Marshall
Jörn Kottmann wrote:
>
>> Here's another (probably weak) use case for returning > AbstractCas> kinds of things: If you have part of the code which
>> collects views and some of these views use one form of the AbstractCas
>> (e.g. CASImpl) and others use the JCas form, it would be nice to be able
>
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> The proposed changes would move the project model out
>> of the Cas Editor into a new project with the advantage that
>> it can be used by other tooling too. Like an analysis engine launcher
>> which needs a document collection to run the AE or a PEA
Jukka Zitting wrote:
> Hi,
>
> On Mon, Aug 10, 2009 at 11:44 AM, Jörn Kottmann wrote:
>
>>> On a related note, have you considered using Iterables instead of
>>> Iterators? They make the looping constructs much nicer.
>>>
>> Its not possible to use Iterables instead of Itertors because
>>
Adam Lally wrote:
> On Mon, Aug 10, 2009 at 10:10 AM, Marshall Schor wrote:
>
>> So, we're back to just the issue (unless another use case can be
>> conceived) of how to iterate, where the uses of the iterator want to use
>> methods from CASImpl. Is the concensus
Adam Lally wrote:
>> Same issue with using Iterator
>> Two quick fixes: casting:
>> Iterator s = (Iterator) aCas.getViewIterator();
>> and
>> Iterator s = aCas.getViewIterator();
>>
>>
>
> Right.. I think it needs to be like this:
>
> > T getViewIterator()
>
I tried this, and get for :
Adam Lally wrote:
> On Mon, Aug 10, 2009 at 12:28 PM, Marshall Schor wrote:
>
>> Adam Lally wrote:
>>
>>>> Same issue with using Iterator
>>>> Two quick fixes: casting:
>>>> Iterator s = (Iterator) aCas.getViewItera
The generification of FSIndex currently specifies one type, that is the type of item being returned.
The contains and find methods have arguments of type FeatureStructure.
These could be changed to take type "T".
I think the current implementation has maybe a bug - if you use contains
or find
Adam Lally wrote:
> On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmann wrote:
>
>> Marshall Schor wrote:
>>
>>> The generification of FSIndex currently specifies one type, >> FeatureStructure> that is the type of item being returned.
>>>
>>
Marshall Schor wrote:
> Adam Lally wrote:
>
>> On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmann wrote:
>>
>>
>>> Marshall Schor wrote:
>>>
>>>
>>>> The generification of FSIndex currently specifies one type
Here's a new thread to discuss just one particular issue - a generics
tradeoff.
In other posts, people have expressed misgivings about letting users
"downcast" List to List, if it cannot be
*guaranteed* at compile time that this is valid.
Here's a simple example, for instance, using two built-in
Thilo Goetz wrote:
> Adam Lally wrote:
>
>> On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schor wrote:
>>
>>> Adam Lally wrote:
>>>
>>>> On Mon, Aug 10, 2009 at 4:07 PM, Jörn Kottmann wrote:
>>>>
>>>>
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> Adam Lally wrote:
>>>
>>>
>>>> On Mon, Aug 10, 2009 at 5:32 PM, Marshall Schor wrote:
>>>>
>>>>
>>>
K
List sln2 = sbox.getL(): // fails, no fix available
}
}
-Marshall
Marshall Schor wrote:
> Here's a new thread to discuss just one particular issue - a generics
> tradeoff.
>
> In other posts, people have expressed misgivings about letting users
> "down
Thilo Goetz wrote:
> Marshall Schor wrote:
>
>> Thilo Goetz wrote:
>>
>>> Marshall Schor wrote:
>>>
>>>
>>>> Thilo Goetz wrote:
>>>>
>>>>
>>>>> Adam Lally wrote:
>
I can see Adam's point.
If there was some way to do an explicit cast that worked for
collections, then I would be happy with that.
In other words, if we had something of type List and I knew the
list really contained only Integers, if there was a way to cast this:
List i_know_what_i_m_doing =
The affected projects are:
uima-as-distr
uima-as-docbooks
uimaj-as
uimaj-as-activemq
uimaj-as-camel
uimaj-as-core
uimaj-as-jms
uimaj-as-osgi-runtime
uimaj-eclipse-feature-deployeditor
uimaj-ep-deployeditor
uimaj-ep-runtime-deployeditor
-Marshall
Jörn Kottmann wrote:
> Adam Lally wrote:
>> On Wed, Aug 12, 2009 at 5:54 AM, Jörn Kottmann
>> wrote:
>>
>>> Yes, but if someone writes it intentional he would get the same
>>> exception during class casting. That means not doing it would only help
>>> someone who picks the wrong type for the vari
Jörn Kottmann wrote:
> Hi,
>
> after all the discussion we had I think thats the correct
> way to generify FSIndexRepository:
>
> interface FSIndexRepository {
> FSIndex getIndex(String label);
> FSIterator getAllIndexedFS(Type aType);
> ...
> }
>
+1 Marshall
> Jörn
>
>
https://issues.apache.org/jira/browse/UIMA-1356 wants to have source
with jars used in the Eclipse plugins. After fiddling with doing that,
I got things working up to adding to the "runtime" jars. Then I
realized, that these jars have other jars inside them... and things were
already pretty compl
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Jörn Kottmann wrote:
>>
>>> Jörn Kottmann wrote:
>>>
Jörn Kottmann wrote:
> Hi,
>
> after all the discussion we had I think thats the correct
> way to generify FSIndexRepository:
>
> interface
Thilo Goetz wrote:
> Jörn Kottmann wrote:
>
>> Thilo Goetz wrote:
>>
>>> Jörn Kottmann wrote:
>>>
>>>
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>
>
>> Jörn Kottmann wrote:
>>
>>
>>> Hi,
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> Jörn Kottmann wrote:
>>> Jörn Kottmann wrote:
Hi,
after all the discussion we had I think thats the correct
way to generify FSIndexRepository:
interface FSIndexRepository {
FSIndex getIndex(String label);
FSIte
Tong Fin wrote:
> On Wed, Aug 12, 2009 at 4:12 PM, Marshall Schor wrote:
>
>
>> https://issues.apache.org/jira/browse/UIMA-1356 wants to have source
>> with jars used in the Eclipse plugins. After fiddling with doing that,
>> I got things working up to adding to
This format takes a long time to generate, and seems on marginally more
compressed than the tar.gz formats. We've never generated it for the
uima-as distr; I'd like to update our build to drop it from the uima
base and sandbox distrs too.
Any objections?
-Marshall
Sounds interesting. If possible, can you post some links to more
information
about what it is?
-Marshall
Ahmed Abdeen Hamed wrote:
> Hello UIMA developers and engineers,
> I have been developing an Ontology-Based Annotator UIMA component for over a
> year now. The Annotator is based on the Conce
Eddie Epstein wrote:
> +1
>
> On the other hand, aren't people on uima-users more likely to care?
>
OK, I'll ask there too... no need to respond there if you've already
done so here
-Marshall
> Eddie
>
> On Mon, Aug 17, 2009 at 3:22 PM, Marshall Schor wro
Jörn Kottmann wrote:
> The additionalParams Map has a String key and can contains
> all kinds of Objects, so the correct generification would be
> Map.
>
> In the uima code base I found one invocation where a Properties object
> was
> passed as additionalParams. Properties is a Map which
> will cau
If you have it checked out, please switch to the new location:
https://svn.apache.org/repos/asf/incubator/uima/uimaj/trunk/PearPackagingMavenPlugin
-Marshall
Jörn Kottmann wrote:
> Marshall Schor wrote:
>> Jörn Kottmann wrote:
>>
>>> The additionalParams Map has a String key and can contains
>>> all kinds of Objects, so the correct generification would be
>>> Map.
>>>
>>> In the uim
The current docs for the pear packaging maven plugin say that you need
to make your project depend on the plugin, by adding it to the
dependency set of your project that is using it.
I don't think this is correct. I think that the maven plugin tools are
specified separately from the project depen
Marshall Schor wrote:
> The current docs for the pear packaging maven plugin say that you need
> to make your project depend on the plugin, by adding it to the
> dependency set of your project that is using it.
>
> I don't think this is correct. I think that the ma
+1 Marshall
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> Marshall Schor wrote:
>>> Jörn Kottmann wrote:
>>>
>>>> The additionalParams Map has a String key and can contains
>>>> all kinds of Objects, so the correct generification would be
&g
> to move our release a few days and use the time to convert existing
> code outside of the core. That could be done after the code freeze.
>
> Jörn
>
> Marshall Schor wrote:
>> I'd like to freeze in 3 weeks, if that is reasonable. For all of you
>> with code that yo
While working on including the BSFAnnotator in the sandbox release, I
noticed it has 6 jar files in its "lib" directory. The NOTICE file says
that the project includes some components under MPL and SPL; however,
the information needed to associate each of this included 3rd-party jar
files with the
Jörn Kottmann wrote:
> Is that the correct generification?
> Class getRequiredCasInterface();
>
> Implementing classes can then specify the concrete return
> type.
>
> For example:
> Class JCasAnnotator_ImplBase.getRequiredCasInterface()
> Class CasAnnotator_ImplBase.getRequiredCasInterface()
I t
Olivier Terrier wrote:
> Hi Marshall
>
> When I donated the BSFAnnotator about two years ago I was not very
> familiar with the maven-based Apache UIMA build process... And I'm
> afraid I'm still not be.
>
>
>> While working on including the BSFAnnotator in the sandbox release, I
>> noticed it
Hi Olivier -
I updated the project:
removed the bsf-bsh.jar
updated the bsh.jar to bsh-1.3.0.jar
I changed the POM so it didn't depend on the bsf-bsh.jar and changed the
dependency of the bsh.jar to bsh-1.3.0.jar.
When I tried to build it, it failed when running the
testAnnotatorAggregated.
org.apache.commons.io.FileUtils is not listed in the dependencies, so
this is an unresolved reference.
I'm not sure how it worked before.
Is the right fix to just add a dependency on org.apache.commons.io? If
we do that, I'm guessing we don't have to distribute it, because maven
will fetch it whe
Adam Lally wrote:
> On Fri, Aug 21, 2009 at 7:48 AM, Jörn Kottmann wrote:
>
>> Jörn Kottmann wrote:
>>
>>> Right now its declared as
>>>
>>> AbstractCas getCasInterface(CAS cas, Class
>>> requiredInterface);
>>>
>>> but I think it should be
>>>
>>> T getCasInterface(CAS cas, Class>> Abst
Olivier Terrier (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/UIMA-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Olivier Terrier updated UIMA-1506:
> --
>
> Attachment: BSFAnnotator.zip
>
> Marshall: I did a q
Marshall Schor wrote:
> Olivier Terrier (JIRA) wrote:
>
>> [
>> https://issues.apache.org/jira/browse/UIMA-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Olivier Terrier updated UIMA-1506:
>> -
After generification of iterators, this line in Lucas doesn't compile:
In src/main/java, org.apache.uima.lucas.indexer.analysis,
the class: AnnotationTokenStream
line 340:
annotationIterator =
Iterators.filter(jCas.getAnnotationIndex(annotationType).iterator(),
new NotNullPredicat
The current dependency is specified as 0.2, but the Tika project is now
at 0.4 release. I don't know if changing to 0.4 requires any concurrent
modifications to the annotator.
-Marshall
Jörn Kottmann wrote:
> public interface JFSIndexRepository {
>
> FSIndex getIndex(String label);
> FSIndex getIndex(String label, int type);
> AnnotationIndex getAnnotationIndex();
> AnnotationIndex getAnnotationIndex(int type);
> Iterator> getIndexes();
> FSIterator getAllIndexedFS(Type aT
Olivier Terrier wrote:
>>> One question: The POM for this project specifies that the Jar have
>>> included "resources", which then become available on the class path.
>>>
>>> The resources included are
>>> BeanshellTestAnnotator.xml
>>> BSFAggregatedAE.xml
>>> BSFAnnotator.xml
>>> NICKNA
701 - 800 of 3230 matches
Mail list logo
