You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2007/10/01 16:40:32 UTC
Issues with PEAR files
I added 2 more issues to https://issues.apache.org/jira/browse/UIMA-583
for things not working with the PEAR inside an Aggregate implementation.
Ideally, for the cleanest architecture (the one with fewest
restrictions, where things work the way people would expect) these
restrictions should be removed, rather than documented, I think. But
that may be low priority...
-Marshall
Re: Issues with PEAR files
Posted by Danai Wiriyayanyongsuk <da...@gmail.com>.
On 10/2/07, Michael Baessler <mb...@michael-baessler.de> wrote:
>
> Indeed in your scenario I understand that it would be very helpful if we
> could override the PEAR parameters in an aggregate AE.
> But please see my comments in the mail trail "Hotfix or next release".
>
> I think we should discuss the UIMA class loading extension you added to
> the UIMA requirements page
>
> http://cwiki.apache.org/confluence/display/UIMA/UIMA+Requirements?showComments=true#comments
> and see what's possible within UIMA when implementing this. I think that
> fits more to your scenario.
>
> -- Michael
>
Thanks Michael. That sounds like a good alternative. Please feel free to let
me know if you have any questions/suggestions regarding the feature I posted
in the requirements page.
Re: Issues with PEAR files
Posted by Michael Baessler <mb...@michael-baessler.de>.
Indeed in your scenario I understand that it would be very helpful if we
could override the PEAR parameters in an aggregate AE.
But please see my comments in the mail trail "Hotfix or next release".
I think we should discuss the UIMA class loading extension you added to
the UIMA requirements page
http://cwiki.apache.org/confluence/display/UIMA/UIMA+Requirements?showComments=true#comments
and see what's possible within UIMA when implementing this. I think that
fits more to your scenario.
-- Michael
Danai Wiriyayanyongsuk wrote:
> Hi UIMA folks,
>
> If I could vote, I'd like to vote for fixing it to allow the overriding of
> the configuration parameters (via AE or any better ways). The project I'm
> working on requires that the parameters shall be configurable at runtime (
> i.e. via AE) and each annotator's class loader should be isolated
> (therefore, PEAR is needed as there is no alternative I guess). I couldn't
> imagine the situation where all PEAR related files need to be duplicated
> (and cleaned up) on disk for each set of the configuration parameters to
> accommodate the configuration changes at runtime.
>
> I appreciate your consideration and thoughts.
>
> Best,
> Danai Wiriyayanyongsuk
>
> On 10/1/07, Marshall Schor <ms...@schor.com> wrote:
>
>> Thilo Goetz wrote:
>>
>>> These are all separate issues and should have different
>>> Jira issues. Like this, you fix one and can't close
>>> the issue.
>>>
>>>
>> This seems true, in general. Sorry about that. I guess I thought that
>> since this was a documentation change (as written), about limitations on
>> Pear file use, that it would be good to get all the restrictions written
>> coherently together.
>>
>> -Marshall
>>
>>> --Thilo
>>>
>>> Marshall Schor wrote:
>>>
>>>
>>>> I added 2 more issues to https://issues.apache.org/jira/browse/UIMA-583
>>>> for things not working with the PEAR inside an Aggregate
>>>>
>> implementation.
>>
>>>> Ideally, for the cleanest architecture (the one with fewest
>>>> restrictions, where things work the way people would expect) these
>>>> restrictions should be removed, rather than documented, I think. But
>>>> that may be low priority...
>>>>
>>>> -Marshall
>>>>
>>>>
>>>
>>>
>>
>
>
Re: Issues with PEAR files
Posted by Danai Wiriyayanyongsuk <da...@gmail.com>.
Hi UIMA folks,
If I could vote, I'd like to vote for fixing it to allow the overriding of
the configuration parameters (via AE or any better ways). The project I'm
working on requires that the parameters shall be configurable at runtime (
i.e. via AE) and each annotator's class loader should be isolated
(therefore, PEAR is needed as there is no alternative I guess). I couldn't
imagine the situation where all PEAR related files need to be duplicated
(and cleaned up) on disk for each set of the configuration parameters to
accommodate the configuration changes at runtime.
I appreciate your consideration and thoughts.
Best,
Danai Wiriyayanyongsuk
On 10/1/07, Marshall Schor <ms...@schor.com> wrote:
>
> Thilo Goetz wrote:
> > These are all separate issues and should have different
> > Jira issues. Like this, you fix one and can't close
> > the issue.
> >
> This seems true, in general. Sorry about that. I guess I thought that
> since this was a documentation change (as written), about limitations on
> Pear file use, that it would be good to get all the restrictions written
> coherently together.
>
> -Marshall
> > --Thilo
> >
> > Marshall Schor wrote:
> >
> >> I added 2 more issues to https://issues.apache.org/jira/browse/UIMA-583
> >> for things not working with the PEAR inside an Aggregate
> implementation.
> >>
> >> Ideally, for the cleanest architecture (the one with fewest
> >> restrictions, where things work the way people would expect) these
> >> restrictions should be removed, rather than documented, I think. But
> >> that may be low priority...
> >>
> >> -Marshall
> >>
> >
> >
> >
>
>
Re: Issues with PEAR files
Posted by Marshall Schor <ms...@schor.com>.
Thilo Goetz wrote:
> These are all separate issues and should have different
> Jira issues. Like this, you fix one and can't close
> the issue.
>
This seems true, in general. Sorry about that. I guess I thought that
since this was a documentation change (as written), about limitations on
Pear file use, that it would be good to get all the restrictions written
coherently together.
-Marshall
> --Thilo
>
> Marshall Schor wrote:
>
>> I added 2 more issues to https://issues.apache.org/jira/browse/UIMA-583
>> for things not working with the PEAR inside an Aggregate implementation.
>>
>> Ideally, for the cleanest architecture (the one with fewest
>> restrictions, where things work the way people would expect) these
>> restrictions should be removed, rather than documented, I think. But
>> that may be low priority...
>>
>> -Marshall
>>
>
>
>
Re: Issues with PEAR files
Posted by Thilo Goetz <tw...@gmx.de>.
These are all separate issues and should have different
Jira issues. Like this, you fix one and can't close
the issue.
--Thilo
Marshall Schor wrote:
> I added 2 more issues to https://issues.apache.org/jira/browse/UIMA-583
> for things not working with the PEAR inside an Aggregate implementation.
>
> Ideally, for the cleanest architecture (the one with fewest
> restrictions, where things work the way people would expect) these
> restrictions should be removed, rather than documented, I think. But
> that may be low priority...
>
> -Marshall