[jira] Commented: (UIMA-1410) The uimaj-as-camel producer should report and log all error/exceptions
[ https://issues.apache.org/jira/browse/UIMA-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742259#action_12742259 ] Jörn Kottmann commented on UIMA-1410: - No should be ready for 2.3.0. > The uimaj-as-camel producer should report and log all error/exceptions > -- > > Key: UIMA-1410 > URL: https://issues.apache.org/jira/browse/UIMA-1410 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Affects Versions: 2.3AS >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann > Fix For: 2.3AS > > > There are several TODOs in the implementation which must be replaced with > proper error handling and logging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] generics: have methods returning objects infer the type from the receiving variable type
Marshall Schor wrote: On the normal scale of -1, 0, +1, to the proposition - have the generic form of many methods that are in the public API for UIMA that return UIMA objects, return a type which is inferred from the receiving typed variable, versus having it return just one fixed type not inferred from the receiving typed variable, Marshall: + .5 (somewhat in favor, but can live with not doing inference, perhaps implementing "internal" versions) -1, but there are a very few methods where type inferring from the receiving typed variable would improve the calling code. Jörn
Re: clarifying a generics issue
Jörn Kottmann wrote:
Marshall Schor wrote:
I'll probably stop trying to convince others if they continue to feel
that the tradeoffs here should be in the direction of returning only
specific types (disallowing users from specifying downcasting in that
manner), versus using types of the form T extends X,
which allows users to specify downcasting.
The case of FSIndexRepository is maybe more clear
then the other cases in our API.
With down casting it could be changed to
interface FSIndexRepository {
FSIndex getIndex(String label);
FSIterator getAllIndexedFS(Type aType);
...
}
and then a user could write
FSIndex index = repo.getIndex(...);
FSIterator it = repo.getAllIndexedFS(...);
Any opinions on this ? Right now the class is not generified but I
would like to change that before the release.
Jörn
Re: clarifying a generics issue
Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>> Marshall Schor wrote:
>>> I'll probably stop trying to convince others if they continue to feel
>>> that the tradeoffs here should be in the direction of returning only
>>> specific types (disallowing users from specifying downcasting in that
>>> manner), versus using types of the form T extends X,
>>> which allows users to specify downcasting.
>>>
>> The case of FSIndexRepository is maybe more clear
>> then the other cases in our API.
>>
>> With down casting it could be changed to
>>
>> interface FSIndexRepository {
>> FSIndex getIndex(String label);
>> FSIterator getAllIndexedFS(Type aType);
>> ...
>> }
>>
>> and then a user could write
>>
>> FSIndex index = repo.getIndex(...);
>> FSIterator it = repo.getAllIndexedFS(...);
> Any opinions on this ? Right now the class is not generified but I
> would like to change that before the release.
>
> Jörn
Will our average user know what this means? If you
think the answer to that is "yes", then I'm for it.
I personally believe the answer is probably "no".
--Thilo
Re: generics: createFilteredIterator
Adam Lally wrote:
On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor wrote:
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 the type of the objects being returned will be the same
as the type of the objects of the iterator passed in.
If the effect of the filtering is to filter the first iterator down to a
subset of the types of the original, this cannot be represented with
this signature.
An alternate generification might be as follows, with type T being the
type the input iterator gives out, and U being the type the filtered
iterator produces:
public FSIterator
createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
return new FilteredIterator(it, cons);}
with the corresponding changes to the class FilteredIterator, and the
CAS interface (to match this new signature).
With these changes, users can write code:
public static void t3(CAS aCas, FSIterator it,
FSMatchConstraint cons) {
FSIterator s = aCas.createFilteredIterator(it, cons);
}
Without these changes, users would be forced to have the filtered
iterator's generic type always equal to the original type.
Is this something we should change (given that we only get one chance to
do our generification)?
I'm not sure. This user's code would compile regardless of whether
the FSMatchConstraint actually implemented the subtype constraint or
not. It's quite possible that the code would compile and then fail
with a ClassCastException.
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 variable by accident, since its
likely that
the code cannot run it will fail immediately.
Another option would be to add a new createFilteredIterator method which
takes a Class object as argument and then reduces its output to objects
which
have the type of the class.
FSIterator createFilteredIterator(...,
Class type)
Since it only returns objects of the correct type T it should not fail.
Jörn
Re: generics: createFilteredIterator
Jörn Kottmann wrote:
> Adam Lally wrote:
>> On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor wrote:
>>
>>> 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 the type of the objects being returned will be the same
>>> as the type of the objects of the iterator passed in.
>>>
>>> If the effect of the filtering is to filter the first iterator down to a
>>> subset of the types of the original, this cannot be represented with
>>> this signature.
>>>
>>> An alternate generification might be as follows, with type T being the
>>> type the input iterator gives out, and U being the type the filtered
>>> iterator produces:
>>>
>>> public FSIterator
>>> createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
>>>return new FilteredIterator(it, cons);}
>>>
>>> with the corresponding changes to the class FilteredIterator, and the
>>> CAS interface (to match this new signature).
>>>
>>> With these changes, users can write code:
>>> public static void t3(CAS aCas, FSIterator it,
>>> FSMatchConstraint cons) {
>>>FSIterator s = aCas.createFilteredIterator(it, cons);
>>> }
>>>
>>> Without these changes, users would be forced to have the filtered
>>> iterator's generic type always equal to the original type.
>>>
>>> Is this something we should change (given that we only get one chance to
>>> do our generification)?
>>>
>>>
>>
>> I'm not sure. This user's code would compile regardless of whether
>> the FSMatchConstraint actually implemented the subtype constraint or
>> not. It's quite possible that the code would compile and then fail
>> with a ClassCastException.
>>
> 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 variable by accident, since its
> likely that
> the code cannot run it will fail immediately.
>
> Another option would be to add a new createFilteredIterator method which
> takes a Class object as argument and then reduces its output to objects
> which
> have the type of the class.
>
> FSIterator createFilteredIterator(...,
> Class type)
>
> Since it only returns objects of the correct type T it should not fail.
>
> Jörn
>
That would work only for the JCas, obviously. However, the JCas
does not use Java classes to represent UIMA types (there's probably
a good reason for that, but I don't know what it is).
--Thilo
Re: generics: createFilteredIterator
Thilo Goetz wrote:
Jörn Kottmann wrote:
Adam Lally wrote:
On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor wrote:
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 the type of the objects being returned will be the same
as the type of the objects of the iterator passed in.
If the effect of the filtering is to filter the first iterator down to a
subset of the types of the original, this cannot be represented with
this signature.
An alternate generification might be as follows, with type T being the
type the input iterator gives out, and U being the type the filtered
iterator produces:
public FSIterator
createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
return new FilteredIterator(it, cons);}
with the corresponding changes to the class FilteredIterator, and the
CAS interface (to match this new signature).
With these changes, users can write code:
public static void t3(CAS aCas, FSIterator it,
FSMatchConstraint cons) {
FSIterator s = aCas.createFilteredIterator(it, cons);
}
Without these changes, users would be forced to have the filtered
iterator's generic type always equal to the original type.
Is this something we should change (given that we only get one chance to
do our generification)?
I'm not sure. This user's code would compile regardless of whether
the FSMatchConstraint actually implemented the subtype constraint or
not. It's quite possible that the code would compile and then fail
with a ClassCastException.
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 variable by accident, since its
likely that
the code cannot run it will fail immediately.
Another option would be to add a new createFilteredIterator method which
takes a Class object as argument and then reduces its output to objects
which
have the type of the class.
FSIterator createFilteredIterator(...,
Class type)
Since it only returns objects of the correct type T it should not fail.
Jörn
That would work only for the JCas, obviously. However, the JCas
does not use Java classes to represent UIMA types (there's probably
a good reason for that, but I don't know what it is).
It can work for both JCas and CAS. In the CAS case the implementation
of the method could use Class.isInstance to filter out objects which
have the wrong type.
Jörn
[jira] Closed: (UIMA-1336) allow multiple dictionary entries to match against a single string
[ https://issues.apache.org/jira/browse/UIMA-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1336. Resolution: Fixed via patch in UIMA-1371 > allow multiple dictionary entries to match against a single string > -- > > Key: UIMA-1336 > URL: https://issues.apache.org/jira/browse/UIMA-1336 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-ConceptMapper >Reporter: Michael Tanenblatt > Attachments: CM-multireturn-patch.txt > > > If multiple dictionary entries contain the same text, only one will be > selected to match against the input text, even if the parameter > "FindAllMatches" is set to true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1336) allow multiple dictionary entries to match against a single string
[ https://issues.apache.org/jira/browse/UIMA-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1336: - Fix Version/s: 2.3S > allow multiple dictionary entries to match against a single string > -- > > Key: UIMA-1336 > URL: https://issues.apache.org/jira/browse/UIMA-1336 > Project: UIMA > Issue Type: Improvement > Components: Sandbox-ConceptMapper >Reporter: Michael Tanenblatt > Fix For: 2.3S > > Attachments: CM-multireturn-patch.txt > > > If multiple dictionary entries contain the same text, only one will be > selected to match against the input text, even if the parameter > "FindAllMatches" is set to true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: createFilteredIterator
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>> Jörn Kottmann wrote:
>>
>>> Adam Lally wrote:
>>>
On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor wrote:
> 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 the type of the objects being returned will be the
> same
> as the type of the objects of the iterator passed in.
>
> If the effect of the filtering is to filter the first iterator down
> to a
> subset of the types of the original, this cannot be represented with
> this signature.
>
> An alternate generification might be as follows, with type T being the
> type the input iterator gives out, and U being the type the filtered
> iterator produces:
>
> public FSIterator
> createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
>return new FilteredIterator(it, cons);}
>
> with the corresponding changes to the class FilteredIterator, and the
> CAS interface (to match this new signature).
>
> With these changes, users can write code:
> public static void t3(CAS aCas, FSIterator it,
> FSMatchConstraint cons) {
>FSIterator s = aCas.createFilteredIterator(it, cons);
> }
>
> Without these changes, users would be forced to have the filtered
> iterator's generic type always equal to the original type.
>
> Is this something we should change (given that we only get one
> chance to
> do our generification)?
>
>
I'm not sure. This user's code would compile regardless of whether
the FSMatchConstraint actually implemented the subtype constraint or
not. It's quite possible that the code would compile and then fail
with a ClassCastException.
>>> 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 variable by accident, since its
>>> likely that
>>> the code cannot run it will fail immediately.
>>>
>>> Another option would be to add a new createFilteredIterator method which
>>> takes a Class object as argument and then reduces its output to objects
>>> which
>>> have the type of the class.
>>>
>>> FSIterator createFilteredIterator(...,
>>> Class type)
>>>
>>> Since it only returns objects of the correct type T it should not fail.
>>>
>>> Jörn
>>>
>>>
>>
>> That would work only for the JCas, obviously. However, the JCas
>> does not use Java classes to represent UIMA types (there's probably
>> a good reason for that, but I don't know what it is).
>>
> It can work for both JCas and CAS. In the CAS case the implementation
> of the method could use Class.isInstance to filter out objects which
> have the wrong type.
>
> Jörn
>
In the CAS there are only FeatureStructures and AnnotationFSs. If
you don't generate JCas classes, you don't have Java classes for
types. Or am I missing something?
--Thilo
Re: generics: createFilteredIterator
Thilo Goetz wrote:
Jörn Kottmann wrote:
Thilo Goetz wrote:
Jörn Kottmann wrote:
Adam Lally wrote:
On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor wrote:
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 the type of the objects being returned will be the
same
as the type of the objects of the iterator passed in.
If the effect of the filtering is to filter the first iterator down
to a
subset of the types of the original, this cannot be represented with
this signature.
An alternate generification might be as follows, with type T being the
type the input iterator gives out, and U being the type the filtered
iterator produces:
public FSIterator
createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
return new FilteredIterator(it, cons);}
with the corresponding changes to the class FilteredIterator, and the
CAS interface (to match this new signature).
With these changes, users can write code:
public static void t3(CAS aCas, FSIterator it,
FSMatchConstraint cons) {
FSIterator s = aCas.createFilteredIterator(it, cons);
}
Without these changes, users would be forced to have the filtered
iterator's generic type always equal to the original type.
Is this something we should change (given that we only get one
chance to
do our generification)?
I'm not sure. This user's code would compile regardless of whether
the FSMatchConstraint actually implemented the subtype constraint or
not. It's quite possible that the code would compile and then fail
with a ClassCastException.
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 variable by accident, since its
likely that
the code cannot run it will fail immediately.
Another option would be to add a new createFilteredIterator method which
takes a Class object as argument and then reduces its output to objects
which
have the type of the class.
FSIterator createFilteredIterator(...,
Class type)
Since it only returns objects of the correct type T it should not fail.
Jörn
That would work only for the JCas, obviously. However, the JCas
does not use Java classes to represent UIMA types (there's probably
a good reason for that, but I don't know what it is).
It can work for both JCas and CAS. In the CAS case the implementation
of the method could use Class.isInstance to filter out objects which
have the wrong type.
Jörn
In the CAS there are only FeatureStructures and AnnotationFSs. If
you don't generate JCas classes, you don't have Java classes for
types. Or am I missing something?
And we have the array types. Sure if you work with a CAS
you certainly almost want AnnotationFS if you don't want FeatureStructure.
But working with annotations is a common case and should work well with
generics.
Re: generics: createFilteredIterator
Jörn Kottmann wrote:
> Thilo Goetz wrote:
>> Jörn Kottmann wrote:
>>
>>> Thilo Goetz wrote:
>>>
Jörn Kottmann wrote:
> Adam Lally wrote:
>
>> On Fri, Aug 7, 2009 at 2:32 PM, Marshall Schor wrote:
>>
>>
>>> 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 the type of the objects being returned will be the
>>> same
>>> as the type of the objects of the iterator passed in.
>>>
>>> If the effect of the filtering is to filter the first iterator down
>>> to a
>>> subset of the types of the original, this cannot be represented with
>>> this signature.
>>>
>>> An alternate generification might be as follows, with type T
>>> being the
>>> type the input iterator gives out, and U being the type the filtered
>>> iterator produces:
>>>
>>> public FSIterator
>>> createFilteredIterator(FSIterator it, FSMatchConstraint cons) {
>>>return new FilteredIterator(it, cons);}
>>>
>>> with the corresponding changes to the class FilteredIterator, and
>>> the
>>> CAS interface (to match this new signature).
>>>
>>> With these changes, users can write code:
>>> public static void t3(CAS aCas, FSIterator it,
>>> FSMatchConstraint cons) {
>>>FSIterator s = aCas.createFilteredIterator(it, cons);
>>> }
>>>
>>> Without these changes, users would be forced to have the filtered
>>> iterator's generic type always equal to the original type.
>>>
>>> Is this something we should change (given that we only get one
>>> chance to
>>> do our generification)?
>>>
>>>
>> I'm not sure. This user's code would compile regardless of whether
>> the FSMatchConstraint actually implemented the subtype constraint or
>> not. It's quite possible that the code would compile and then fail
>> with a ClassCastException.
>>
> 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 variable by accident,
> since its
> likely that
> the code cannot run it will fail immediately.
>
> Another option would be to add a new createFilteredIterator method
> which
> takes a Class object as argument and then reduces its output to
> objects
> which
> have the type of the class.
>
> FSIterator createFilteredIterator(...,
> Class type)
>
> Since it only returns objects of the correct type T it should not
> fail.
>
> Jörn
>
>
That would work only for the JCas, obviously. However, the JCas
does not use Java classes to represent UIMA types (there's probably
a good reason for that, but I don't know what it is).
>>> It can work for both JCas and CAS. In the CAS case the implementation
>>> of the method could use Class.isInstance to filter out objects which
>>> have the wrong type.
>>>
>>> Jörn
>>>
>>>
>>
>> In the CAS there are only FeatureStructures and AnnotationFSs. If
>> you don't generate JCas classes, you don't have Java classes for
>> types. Or am I missing something?
>>
> And we have the array types. Sure if you work with a CAS
> you certainly almost want AnnotationFS if you don't want FeatureStructure.
> But working with annotations is a common case and should work well with
> generics.
>
Whatever. I don't think it's worth the added complexity of
the interface, but if you feel differently, go ahead. I'm
thinking of defecting to Scala land anyway ;-)
--Thilo
[jira] Assigned: (UIMA-1485) UIMA Tutorial and Developers guide in sub title 1.3.2 should be AAE and not AE
[ https://issues.apache.org/jira/browse/UIMA-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1485: Assignee: Marshall Schor > UIMA Tutorial and Developers guide in sub title 1.3.2 should be AAE and not AE > -- > > Key: UIMA-1485 > URL: https://issues.apache.org/jira/browse/UIMA-1485 > Project: UIMA > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.2 >Reporter: Jörn Kottmann >Assignee: Marshall Schor >Priority: Trivial > Fix For: 2.3 > > > "1.3.2. AEs can also contain CAS Consumers" should be "1.3.2. AAEs can also > contain CAS Consumers" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1485) UIMA Tutorial and Developers guide in sub title 1.3.2 should be AAE and not AE
[ https://issues.apache.org/jira/browse/UIMA-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1485. Resolution: Fixed > UIMA Tutorial and Developers guide in sub title 1.3.2 should be AAE and not AE > -- > > Key: UIMA-1485 > URL: https://issues.apache.org/jira/browse/UIMA-1485 > Project: UIMA > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.2 >Reporter: Jörn Kottmann >Assignee: Marshall Schor >Priority: Trivial > Fix For: 2.3 > > > "1.3.2. AEs can also contain CAS Consumers" should be "1.3.2. AAEs can also > contain CAS Consumers" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1426) More control for apps against OOMs from UIMA core: Add configuration option to set the maximum heap size the CAS will grow to
[ https://issues.apache.org/jira/browse/UIMA-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor updated UIMA-1426: - Affects Version/s: 2.3 marking as "affects 2.3" to indicate not being fixed this cycle. > More control for apps against OOMs from UIMA core: Add configuration option > to set the maximum heap size the CAS will grow to > - > > Key: UIMA-1426 > URL: https://issues.apache.org/jira/browse/UIMA-1426 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.3 >Reporter: Thomas Hampp > > Applications need to protect themselves against out of memory exceptions > (OOMs). UIMA should help with that by making sure a growth in the CAS heap > size will not cause an OOM. One way to do this is to add a config param that > controls the maximum heap size for a CAS and throw a runtime exception if > that threshold is exceeded. > Since apps often use multiple CASes in pools in multihreaded fashion they > would still need to exercise some app specific math (and guesswork) to > determine the right value for this param. But at least they would be able to > have some control. > (There could still be OOMs during UIMA processing from other sources) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: clarifying a generics issue
On Wed, Aug 12, 2009 at 5:36 AM, Jörn Kottmann wrote:
> Jörn Kottmann wrote:
>>
>> Marshall Schor wrote:
>>>
>>> I'll probably stop trying to convince others if they continue to feel
>>> that the tradeoffs here should be in the direction of returning only
>>> specific types (disallowing users from specifying downcasting in that
>>> manner), versus using types of the form T extends X,
>>> which allows users to specify downcasting.
>>>
>>
>> The case of FSIndexRepository is maybe more clear
>> then the other cases in our API.
>>
>> With down casting it could be changed to
>>
>> interface FSIndexRepository {
>> FSIndex getIndex(String label);
>> FSIterator getAllIndexedFS(Type aType);
>> ...
>> }
>>
>> and then a user could write
>>
>> FSIndex index = repo.getIndex(...);
>> FSIterator it = repo.getAllIndexedFS(...);
>
> Any opinions on this ? Right now the class is not generified but I
> would like to change that before the release.
>
I say no since like our other discussions, I don't like cases where
there's no guarantee of correctness. A user can write:
FSIterator it = repo.getAllIndexedFS(someNonAnnotationTypeCode);
and it would compile even though it doesn't make sense.
Something like this for JCas, on the other hand, does make sense to me:
FSIterator getAllIndexedFS(Class jcasType)
which is called like
FSIterator it = jcas.getAllIndexedFS(MyAnnotationType.class);
-Adam
Re: generics: createFilteredIterator
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 variable by accident, since its > likely that > the code cannot run it will fail immediately. > If ClassCastExceptions are going to happen I'd *much* rather they be on explicit casts in user code rather than in framework code. It's more straightforward for the user to understand and fix the problem in that case. But really, it more comes down to philosophy. My understanding of how to use generics is that you should use them in places where the API guarantees it complies with the type constraint. That way it makes the API more understandable than just using raw types. I think that putting in things which may or may not work makes the API less understandable and is really not a good idea. I don't believe that using generics just to avoid having to do typecasts is the right idea at all. I'm not aware of cases where that has been done in the Java class libraries, for example - if there are, point them out. This is why I'm fighting tooth and nail against taking UIMA in that direction. > Another option would be to add a new createFilteredIterator method which > takes a Class object as argument and then reduces its output to objects > which > have the type of the class. > > FSIterator createFilteredIterator(..., > Class type) > > Since it only returns objects of the correct type T it should not fail. > Yes, I wouldn't strenuously object to that but I doubt it's usefulness for createFilteredIterator. I do think something like that is nice in JCas for getting an iterator over all instances of a specific type, as I suggested on another thread. -Adam
[jira] Commented: (UIMA-1417) ResourceConfigurationException to be thrown from the initialize(context) method
[ https://issues.apache.org/jira/browse/UIMA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742378#action_12742378 ] Adam Lally commented on UIMA-1417: -- I think the documentation is wrong and should be changed. > ResourceConfigurationException to be thrown from the initialize(context) > method > --- > > Key: UIMA-1417 > URL: https://issues.apache.org/jira/browse/UIMA-1417 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, Documentation >Affects Versions: 2.2.2 > Environment: Windows XP, Java 1.5 >Reporter: nikolay georgiev > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Hello, > In the UIMA Tutorial and Developer's Guide, section "Throwing Exceptions from > Annotators", it is written that one can throw 3 kinds of exceptions, one of > which is the ResourceConfigurationException. And it is written that is good > to read the configuration parameters in the inialize() method, but > unfortunately the initialize() method can throw only > ResourceInitializationException, so I am not able to throw the > ResourceConfigurationException. The method signature is: > public void initialize(UimaContext context) throws > ResourceInitializationException > Can you add also the ResourceConfigurationException or correct the > documentation? > Greetings, > Nikolay -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1487) Add support for collectionProcessComplete timeout setting in JMS service adapter
Add support for collectionProcessComplete timeout setting in JMS service adapter Key: UIMA-1487 URL: https://issues.apache.org/jira/browse/UIMA-1487 Project: UIMA Issue Type: Bug Components: Async Scaleout Reporter: Eddie Epstein Assignee: Eddie Epstein The JMS service adapter is used to allow UIMA aggregates to call UIMA AS services, similar to Vinci and SOAP services. The JMS adapter supports process and getmeta timeouts, but not CPC. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: createFilteredIterator
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 variable by accident, since its likely that the code cannot run it will fail immediately. If ClassCastExceptions are going to happen I'd *much* rather they be on explicit casts in user code rather than in framework code. It's more straightforward for the user to understand and fix the problem in that case. But really, it more comes down to philosophy. My understanding of how to use generics is that you should use them in places where the API guarantees it complies with the type constraint. That way it makes the API more understandable than just using raw types. I think that putting in things which may or may not work makes the API less understandable and is really not a good idea. I don't believe that using generics just to avoid having to do typecasts is the right idea at all. I'm not aware of cases where that has been done in the Java class libraries, for example - if there are, point them out. This is why I'm fighting tooth and nail against taking UIMA in that direction. Another option would be to add a new createFilteredIterator method which takes a Class object as argument and then reduces its output to objects which have the type of the class. FSIterator createFilteredIterator(..., Class type) Since it only returns objects of the correct type T it should not fail. Yes, I wouldn't strenuously object to that but I doubt it's usefulness for createFilteredIterator. I do think something like that is nice in JCas for getting an iterator over all instances of a specific type, as I suggested on another thread. In the end that means that we can leave this method in CAS and JCas like it is right now: FSIterator createFilteredIterator(FSIterator it, FSMatchConstraint cons); A method like I proposed can be added to the CAS interface after the next release if we decide its necessary. Do we want to add the method proposed by Adam for 2.3.0 to JCas ? Jörn
generics: FSIndexRepository
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);
...
}
Jörn
[jira] Created: (UIMA-1488) Generics for org.apache.uima.resoruce classes
Generics for org.apache.uima.resoruce classes - Key: UIMA-1488 URL: https://issues.apache.org/jira/browse/UIMA-1488 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 The org.apache.uima.resoruce should use generics in its classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
generics: additionalParams
The additionalParams Map has a String key and can contains all kinds of Objects, so the correct generification would be MapObject>. In the uima code base I found one invocation where a Properties object was passed as additionalParams. Properties is a Map which will cause compile errors in user code when they use a Properties object to pass in the additional params. I don't think its common practice to use Properties for additional params. Should we change it anyway and add a known issue to our release notes ? Jörn
[jira] Reopened: (UIMA-1433) UIMA AS service creates too many JMS connections
[ https://issues.apache.org/jira/browse/UIMA-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Cwiklik reopened UIMA-1433: - Cleanup global connection Map when inactivity timer on a reply queue pops > UIMA AS service creates too many JMS connections > - > > Key: UIMA-1433 > URL: https://issues.apache.org/jira/browse/UIMA-1433 > Project: UIMA > Issue Type: Bug > Components: Async Scaleout >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > > UIMA AS service maintains connections to client's reply queue. These > connections are cached and reused. When the connection becomes idle for too > long, it is closed. Current default connection timeout is set to 30 minutes. > This value can be changed via System property -DSessionTimeoutOverride=n. > JMS Connections are expensive, and if too many are created the broker may > become unstable. As optimization, the service should create a single JMS > connection (per broker) and use it to create jms sessions and message > producers for each client. This change will reduce number of threads the > broker needs to manage in deployments where clients and services use a single > broker for messaging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: createFilteredIterator
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 variable by accident, since >>> its >>> likely that >>> the code cannot run it will fail immediately. >>> >>> >> >> If ClassCastExceptions are going to happen I'd *much* rather they be >> on explicit casts in user code rather than in framework code. It's >> more straightforward for the user to understand and fix the problem in >> that case. >> >> But really, it more comes down to philosophy. My understanding of how >> to use generics is that you should use them in places where the API >> guarantees it complies with the type constraint. That way it makes >> the API more understandable than just using raw types. I think that >> putting in things which may or may not work makes the API less >> understandable and is really not a good idea. I don't believe that >> using generics just to avoid having to do typecasts is the right idea >> at all. I'm not aware of cases where that has been done in the Java >> class libraries, for example - if there are, point them out. This is >> why I'm fighting tooth and nail against taking UIMA in that direction. >> >> >>> Another option would be to add a new createFilteredIterator method >>> which >>> takes a Class object as argument and then reduces its output to objects >>> which >>> have the type of the class. >>> >>> FSIterator createFilteredIterator(..., >>> Class type) >>> >>> Since it only returns objects of the correct type T it should not fail. >>> >>> >> >> Yes, I wouldn't strenuously object to that but I doubt it's usefulness >> for createFilteredIterator. I do think something like that is nice in >> JCas for getting an iterator over all instances of a specific type, as >> I suggested on another thread. >> > In the end that means that we can leave this method in CAS and JCas > like it is right now: > FSIterator > createFilteredIterator(FSIterator it, FSMatchConstraint cons); > +1 > A method like I proposed can be added to the CAS interface after the > next release if we decide > its necessary. Do we want to add the method proposed by Adam for 2.3.0 > to JCas ? Adam's suggested method proposed in another thread was: FSIterator getAllIndexedFS(Class jcasType) This method is on a particular index, or on an instance of the JFSIndexRepository (or the equivalent non-JCas one). Currently the JFSIndexRepository doesn't have methods for returning iterators picked by [Class jcasType], but I think these could be easily added, and I'm +1 for this. There are also methods on the JCas itself for returning instances of AnnotationIndex public AnnotationIndex getAnnotationIndex(Type type) I would also be +1 for adding a version of this: public AnnotationIndex getAnnotationIndex(Class jcasType) I would also be +1 for adding versions of getAllIndexedFS to the JCasImpl itself, avoiding the need to do aJCas.getJFSIndexRepository().getAllIndexedFS... which I think is more an implementation detail than a needed API feature. (please correct this impression if I'm mistaken...). -Marshall > > Jörn >
Re: generics: FSIndexRepository
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
>
>
issue with adding source to jars
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 complex. An alternative would be to have just one jar with all the sources in it, and we would get rid of add-sources-to-jar things. Users wanting to have Eclipse (and maybe other IDEs?) locate the source would be pointed to this jar. Eclipse supports this, AFAIK. The add-sources-to-jar would be replaced with a script to build all the sources into one jar. Opinions? -Marshall
Re: generics: FSIndexRepository
On Wed, Aug 12, 2009 at 10:52 AM, 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
-Adam
[jira] Assigned: (UIMA-1356) Add source to UIMA Eclipse plugins
[ https://issues.apache.org/jira/browse/UIMA-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1356: Assignee: Marshall Schor > Add source to UIMA Eclipse plugins > -- > > Key: UIMA-1356 > URL: https://issues.apache.org/jira/browse/UIMA-1356 > Project: UIMA > Issue Type: Improvement > Components: Eclipse plugins >Reporter: Kai Schlamp >Assignee: Marshall Schor > > Sources added by the addSourceToJars script are only added to the jar files > under the lib folder of UIMA_HOME and not to the Eclipse UIMA plugins. So if > you use those plugins for development, then the sources can't be accessed in > Eclipse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: createFilteredIterator
On Wed, Aug 12, 2009 at 3:08 PM, Marshall Schor wrote: > 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 variable by accident, since its likely that the code cannot run it will fail immediately. >>> >>> If ClassCastExceptions are going to happen I'd *much* rather they be >>> on explicit casts in user code rather than in framework code. It's >>> more straightforward for the user to understand and fix the problem in >>> that case. >>> >>> But really, it more comes down to philosophy. My understanding of how >>> to use generics is that you should use them in places where the API >>> guarantees it complies with the type constraint. That way it makes >>> the API more understandable than just using raw types. I think that >>> putting in things which may or may not work makes the API less >>> understandable and is really not a good idea. I don't believe that >>> using generics just to avoid having to do typecasts is the right idea >>> at all. I'm not aware of cases where that has been done in the Java >>> class libraries, for example - if there are, point them out. This is >>> why I'm fighting tooth and nail against taking UIMA in that direction. >>> >>> Another option would be to add a new createFilteredIterator method which takes a Class object as argument and then reduces its output to objects which have the type of the class. FSIterator createFilteredIterator(..., Class type) Since it only returns objects of the correct type T it should not fail. >>> >>> Yes, I wouldn't strenuously object to that but I doubt it's usefulness >>> for createFilteredIterator. I do think something like that is nice in >>> JCas for getting an iterator over all instances of a specific type, as >>> I suggested on another thread. >>> >> In the end that means that we can leave this method in CAS and JCas >> like it is right now: >> FSIterator >> createFilteredIterator(FSIterator it, FSMatchConstraint cons); >> > +1 >> A method like I proposed can be added to the CAS interface after the >> next release if we decide >> its necessary. Do we want to add the method proposed by Adam for 2.3.0 >> to JCas ? > Adam's suggested method proposed in another thread was: > > FSIterator getAllIndexedFS(Class jcasType) > > This method is on a particular index, or on an instance of the > JFSIndexRepository (or the equivalent non-JCas one). > > Currently the JFSIndexRepository doesn't have methods for returning iterators > picked by [Class jcasType], but I think these could be easily added, and > I'm +1 for this. > > There are also methods on the JCas itself for returning instances of > AnnotationIndex > public AnnotationIndex getAnnotationIndex(Type type) > > I would also be +1 for adding a version of this: > public AnnotationIndex getAnnotationIndex(Class > jcasType) > > I would also be +1 for adding versions of getAllIndexedFS to the JCasImpl > itself, avoiding the need to do > aJCas.getJFSIndexRepository().getAllIndexedFS... which I think is more an > implementation detail than a needed API feature. (please correct this > impression if I'm mistaken...). > +1 to all. BTW, see here for an implementation I posted previously of a method for returning an Iterable over a specfic FS type. Of course we can also have a method that returns the iterator itself. http://www.mail-archive.com/uima-dev@incubator.apache.org/msg04657.html -Adam
[jira] Assigned: (UIMA-1400) Uima aggregate with embedded Cas Multiplier fails if one attempts to create multiple instances of it in the same JVM
[ https://issues.apache.org/jira/browse/UIMA-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor reassigned UIMA-1400: Assignee: Jerry Cwiklik Jerry - can you update the status of this in preparation for 2.3.0 release? > Uima aggregate with embedded Cas Multiplier fails if one attempts to create > multiple instances of it in the same JVM > > > Key: UIMA-1400 > URL: https://issues.apache.org/jira/browse/UIMA-1400 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.2.2 >Reporter: Jerry Cwiklik >Assignee: Jerry Cwiklik > > When trying to scale Uima aggregate with a Cas Multiplier in the same JVM, > the code fails with the following: > org.apache.uima.analysis_engine.AnalysisEngineProcessException: The > method CasManager.defineCasPool() was called twice by the same Analysis > Engine > This is due to the fact that the CasManager creates a single CAS pool for any > given Cas Multiplier, no matter how many instances of it are created. The > first instance of a particular CM creates a CAS Pool and the pool is > associated with that instance using a CM's qualified name obtained from the > component's uima context. The second instance of the same CM fails, since its > trying to create another CAS pool with the same qualified name as the first > instance. > Create and assign a unique name in the Uima context for each instance of a > component. Use the unique name when calling defineCasPool() so that every > instance of the CM component creates its own CAS pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1417) ResourceConfigurationException to be thrown from the initialize(context) method
[ https://issues.apache.org/jira/browse/UIMA-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marshall Schor closed UIMA-1417. Resolution: Fixed Fix Version/s: 2.3 Assignee: Marshall Schor corrected documentation. > ResourceConfigurationException to be thrown from the initialize(context) > method > --- > > Key: UIMA-1417 > URL: https://issues.apache.org/jira/browse/UIMA-1417 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework, Documentation >Affects Versions: 2.2.2 > Environment: Windows XP, Java 1.5 >Reporter: nikolay georgiev >Assignee: Marshall Schor > Fix For: 2.3 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Hello, > In the UIMA Tutorial and Developer's Guide, section "Throwing Exceptions from > Annotators", it is written that one can throw 3 kinds of exceptions, one of > which is the ResourceConfigurationException. And it is written that is good > to read the configuration parameters in the inialize() method, but > unfortunately the initialize() method can throw only > ResourceInitializationException, so I am not able to throw the > ResourceConfigurationException. The method signature is: > public void initialize(UimaContext context) throws > ResourceInitializationException > Can you add also the ResourceConfigurationException or correct the > documentation? > Greetings, > Nikolay -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-1489) Generify FSIndexRepository
Generify FSIndexRepository -- Key: UIMA-1489 URL: https://issues.apache.org/jira/browse/UIMA-1489 Project: UIMA Issue Type: Improvement Components: Core Java Framework Reporter: Jörn Kottmann Assignee: Jörn Kottmann Fix For: 2.3 Add generics to the FSIndexRepository interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: FSIndexRepository
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);
...
}
It generified now and also getIndexes:
Iterator> getIndexes();
Jörn
[jira] Closed: (UIMA-1489) Generify FSIndexRepository
[ https://issues.apache.org/jira/browse/UIMA-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann closed UIMA-1489. --- Resolution: Fixed > Generify FSIndexRepository > -- > > Key: UIMA-1489 > URL: https://issues.apache.org/jira/browse/UIMA-1489 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann > Fix For: 2.3 > > > Add generics to the FSIndexRepository interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1458) Remove the Cas Editor from the sandbox page.
[ https://issues.apache.org/jira/browse/UIMA-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann updated UIMA-1458: Fix Version/s: 2.3 > Remove the Cas Editor from the sandbox page. > > > Key: UIMA-1458 > URL: https://issues.apache.org/jira/browse/UIMA-1458 > Project: UIMA > Issue Type: Bug > Components: Website >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann >Priority: Minor > Fix For: 2.3 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-1408) Annotation highlightning does not work with background drawing strategy
[ https://issues.apache.org/jira/browse/UIMA-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742648#action_12742648 ] Jörn Kottmann commented on UIMA-1408: - I looked into this issue and could not find a way to solve it. If it cannot be fixed for 2.3.0, the default drawing style should be changed to something else then the background drawing strategy. > Annotation highlightning does not work with background drawing strategy > --- > > Key: UIMA-1408 > URL: https://issues.apache.org/jira/browse/UIMA-1408 > Project: UIMA > Issue Type: Bug > Components: CasEditor >Affects Versions: 2.3 >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann >Priority: Minor > > An annotation which is visualized with the background drawing strategy in the > cas text edtiro is not highlighted when selected in the outline view. The > annotation appearance should change to give the user a feedback which > annotation is selected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: generics: getViewIterator
Marshall Schor wrote: Sounds right. But we should use bounded wildcards for "arguments" where appropriate (of course, this doesn't apply to getViewIterator, which has no arguments). The article, http://www.ibm.com/developerworks/java/library/j-jtp07018.html?S_TACT=105AGX02&S_CMP=EDU has a nice "principle" called the "get-put" principle for arguments: Use an |extends| wildcard when you only get values out of a structure, use a |super| wildcard when you only put values into a structure, and don't use a wildcard when you do both. For the last part, he also says the reason for not using a wild card if you do both: If you can put a |T| or any of its subtypes, and you can get a |T| or any of its supertypes, then the only thing you can both get and put is a |T| itself. Well, I was aware of the get part, but it does not always makes sense, in my eyes, e.g. when a method receives a List from somewhere. I never used the put part of the rule, which may indicate I did something wrong in a very few places, because output Lists for example are rarely used. Jörn
Re: generics: FSIndexRepository
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);
FSIterator getAllIndexedFS(Type aType);
...
}
It generified now and also getIndexes:
Iterator> getIndexes();
Stupid question, but how can a FSIndex be converted
into a FSIndex ? Since casting directy is not possible,
do I need to write some kind of adapter which does the casting for me ?
Jörn
[jira] Reopened: (UIMA-1489) Generify FSIndexRepository
[ https://issues.apache.org/jira/browse/UIMA-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Kottmann reopened UIMA-1489: - > Generify FSIndexRepository > -- > > Key: UIMA-1489 > URL: https://issues.apache.org/jira/browse/UIMA-1489 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Jörn Kottmann >Assignee: Jörn Kottmann > Fix For: 2.3 > > > Add generics to the FSIndexRepository interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: issue with adding source to jars
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 the "runtime" jars. Then I > realized, that these jars have other jars inside them... and things were > already pretty complex. > > An alternative would be to have just one jar with all the sources in it, > and we would get rid of add-sources-to-jar things. Users wanting to have > Eclipse (and maybe other IDEs?) locate the source would be pointed to > this jar. Eclipse supports this, AFAIK. > > The add-sources-to-jar would be replaced with a script to build all the > sources into one jar. > > Opinions? > > -Marshall > > Just for info, starting from Eclipse 3.5, the preferred approach is to create a "source" plugin that will behave and be installed as ordinary plugin. But, since we are using maven, we may have some difficulty to build those "source plugins". (BTW, I never try to create the "source" plugin). -- Tong
