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/04/12 04:14:18 UTC
Re: s in UIMA descriptors
Adam Lally wrote:
> On 3/26/07, Thilo Goetz <tw...@gmx.de> wrote:
>> I agree that people may be using it. I haven't seen it used in a while,
>> but that doesn't mean anything. If we don't plan on removing the
>> feature, why should we deprecate it?
>>
>> The name is because we wanted no difference between Java and C++
>> descriptors. System properties are the way to do env vars in Java.
>> System env vars are deprecated in Java. So I'd vote to leave things as
>> they are. If the CDE doesn't support this (documented and I assume,
>> working) feature, maybe we should add that support?
>>
>
> BTW, System.getEnv is no longer deprecated in Java 5. But I'm not
> sure that really helps us, since at present we're still committing to
> support Java 1.4.
>
> -Adam
>
>
In Java 1.4, although it's marked as deprecated, it is available. And
it's no longer
deprecated in Java 5 or Java 6. So we could change this to
access environment variables directly, right? Then it would match the
C++ impl.
-Marshall
Re: s in UIMA descriptors
Posted by Adam Lally <al...@alum.rpi.edu>.
On 4/11/07, Marshall Schor <ms...@schor.com> wrote:
> > BTW, System.getEnv is no longer deprecated in Java 5. But I'm not
> > sure that really helps us, since at present we're still committing to
> > support Java 1.4.
> >
>
> In Java 1.4, although it's marked as deprecated, it is available.
But I believe it does not actually work. :(
-Adam
Re: Installer in UIMA Apache
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally wrote:
> On 4/15/07, Benjamin Sznajder <be...@il.ibm.com> wrote:
>> Hi,
>>
>> I used until now the IBM UIMA (from watson's site) and I am passing
>> now to
>> the Apache version.
>> I permit myself to suggest the following:
>> In IBM version, the user was able to download the installer that made
>> for
>> him all the work. Why there is not such utility in Apache's version,
>> namely
>> an installer that would set the desired property values?
>>
>
> Primarily this is because InstallShield is not free, and now that
> we're at Apache we prefer using freely available tools to build our
> distribution. There might be a free alternative we could try (I
> haven't looked), but it doesn't seem to be common among Apache
> projects to provide an installer.
>
>
>> In addition, I think that there is no clear information about how to
>> install the UIMA Sdk. In fact, there is no real intuitive place where
>> the
>> user can find this information. It is only said "by the way" in the
>> documentation.
>>
>
> The README is intended to provide this information. Is there any
> important information that you could not find there?
>
>
>> And a last question: why is the README file (in the zip) with no
>> suffix ?
>> Why .txt is not suitable?
>>
>
> It seemed to be a common Apache convention, although it's not an
> absolute rule and some other projects do use .txt. I don't feel
> strongly about it either way. Anyone else have an opinion?
My opinion is to use .txt - it makes the Eclipse IDE (and maybe others)
behave better :-)
-Marshall
>
> -Adam
>
>
Re: Installer in UIMA Apache
Posted by Marshall Schor <ms...@schor.com>.
Benjamin Sznajder wrote:
> Hi Adam,
>
> Refering to your mail, I think that the user is not "aware" about this
> README file. You may mention its existence in the download page, maybe?
>
> Benjamin
>
Hi Benjamin -
We're trying to attract additional people to contribute to UIMA. You've
made some good suggestions, and I'd like to invite
you to contribute a "patch" for our webpage, changing it in the way you
think it would best communicate this information.
If you do that, I'll review it quickly and get the web page updated.
Thanks for your help! -Marshall
>
>
> "Adam Lally"
> <alally@alum.rpi.
> edu> To
> Sent by: uima-dev@incubator.apache.org
> lally.adam@gmail. cc
> com
> Subject
> Re: Installer in UIMA Apache
> 16/04/2007 16:49
>
>
> Please respond to
> uima-dev@incubato
> r.apache.org
>
>
>
>
>
>
> On 4/15/07, Benjamin Sznajder <be...@il.ibm.com> wrote:
>
>> Hi,
>>
>> I used until now the IBM UIMA (from watson's site) and I am passing now
>>
> to
>
>> the Apache version.
>> I permit myself to suggest the following:
>> In IBM version, the user was able to download the installer that made for
>> him all the work. Why there is not such utility in Apache's version,
>>
> namely
>
>> an installer that would set the desired property values?
>>
>>
>
> Primarily this is because InstallShield is not free, and now that
> we're at Apache we prefer using freely available tools to build our
> distribution. There might be a free alternative we could try (I
> haven't looked), but it doesn't seem to be common among Apache
> projects to provide an installer.
>
>
>
>> In addition, I think that there is no clear information about how to
>> install the UIMA Sdk. In fact, there is no real intuitive place where the
>> user can find this information. It is only said "by the way" in the
>> documentation.
>>
>>
>
> The README is intended to provide this information. Is there any
> important information that you could not find there?
>
>
>
>> And a last question: why is the README file (in the zip) with no suffix ?
>> Why .txt is not suitable?
>>
>>
>
> It seemed to be a common Apache convention, although it's not an
> absolute rule and some other projects do use .txt. I don't feel
> strongly about it either way. Anyone else have an opinion?
>
> -Adam
>
>
>
>
>
Re: Installer in UIMA Apache
Posted by Benjamin Sznajder <be...@il.ibm.com>.
Hi Adam,
Refering to your mail, I think that the user is not "aware" about this
README file. You may mention its existence in the download page, maybe?
Benjamin
"Adam Lally"
<alally@alum.rpi.
edu> To
Sent by: uima-dev@incubator.apache.org
lally.adam@gmail. cc
com
Subject
Re: Installer in UIMA Apache
16/04/2007 16:49
Please respond to
uima-dev@incubato
r.apache.org
On 4/15/07, Benjamin Sznajder <be...@il.ibm.com> wrote:
> Hi,
>
> I used until now the IBM UIMA (from watson's site) and I am passing now
to
> the Apache version.
> I permit myself to suggest the following:
> In IBM version, the user was able to download the installer that made for
> him all the work. Why there is not such utility in Apache's version,
namely
> an installer that would set the desired property values?
>
Primarily this is because InstallShield is not free, and now that
we're at Apache we prefer using freely available tools to build our
distribution. There might be a free alternative we could try (I
haven't looked), but it doesn't seem to be common among Apache
projects to provide an installer.
> In addition, I think that there is no clear information about how to
> install the UIMA Sdk. In fact, there is no real intuitive place where the
> user can find this information. It is only said "by the way" in the
> documentation.
>
The README is intended to provide this information. Is there any
important information that you could not find there?
> And a last question: why is the README file (in the zip) with no suffix ?
> Why .txt is not suitable?
>
It seemed to be a common Apache convention, although it's not an
absolute rule and some other projects do use .txt. I don't feel
strongly about it either way. Anyone else have an opinion?
-Adam
Re: Installer in UIMA Apache
Posted by Adam Lally <al...@alum.rpi.edu>.
On 4/15/07, Benjamin Sznajder <be...@il.ibm.com> wrote:
> Hi,
>
> I used until now the IBM UIMA (from watson's site) and I am passing now to
> the Apache version.
> I permit myself to suggest the following:
> In IBM version, the user was able to download the installer that made for
> him all the work. Why there is not such utility in Apache's version, namely
> an installer that would set the desired property values?
>
Primarily this is because InstallShield is not free, and now that
we're at Apache we prefer using freely available tools to build our
distribution. There might be a free alternative we could try (I
haven't looked), but it doesn't seem to be common among Apache
projects to provide an installer.
> In addition, I think that there is no clear information about how to
> install the UIMA Sdk. In fact, there is no real intuitive place where the
> user can find this information. It is only said "by the way" in the
> documentation.
>
The README is intended to provide this information. Is there any
important information that you could not find there?
> And a last question: why is the README file (in the zip) with no suffix ?
> Why .txt is not suitable?
>
It seemed to be a common Apache convention, although it's not an
absolute rule and some other projects do use .txt. I don't feel
strongly about it either way. Anyone else have an opinion?
-Adam
Installer in UIMA Apache
Posted by Benjamin Sznajder <be...@il.ibm.com>.
Hi,
I used until now the IBM UIMA (from watson's site) and I am passing now to
the Apache version.
I permit myself to suggest the following:
In IBM version, the user was able to download the installer that made for
him all the work. Why there is not such utility in Apache's version, namely
an installer that would set the desired property values?
In addition, I think that there is no clear information about how to
install the UIMA Sdk. In fact, there is no real intuitive place where the
user can find this information. It is only said "by the way" in the
documentation.
And a last question: why is the README file (in the zip) with no suffix ?
Why .txt is not suitable?
Best regards and congratulations to all for this work!!!
Benjamin
Re: s in UIMA descriptors
Posted by Adam Lally <al...@alum.rpi.edu>.
On 4/13/07, Eddie Epstein <ea...@gmail.com> wrote:
> And yet the UIMA SDK run_configurations depends on the environmental
> variable UIMA_HOME:
>
> "-Djava.util.logging.config.file=${env_var:UIMA_HOME}/config/Logger.properties"
> -DVNS_HOST=localhost
>
> Are we being hypocritical here, using environment variables in Java
> when convenient but saying that others should not?
>
_Applications_ can use all the environment variables they want. I
just don't think it's nice for reusable components to require them.
The UIMA framework itself has no environment variable dependency,
these are used only by top level applications/tools, and are
referenced in scripts or run configurations that launch those tools,
not from Java itself.
However, I'm willing to admit that an annotator can access environment
variables (in its code) if it really needs to, and that this may be
necessary for wrapping certain 3rd-party components. But I just don't
think it's a best practice, and am not sure UIMA needs a special
feature to allow environment variable references in its descriptors.
Let people access them through the Java API if they really need to.
-Adam
Re: s in UIMA descriptors
Posted by Eddie Epstein <ea...@gmail.com>.
And yet the UIMA SDK run_configurations depends on the environmental
variable UIMA_HOME:
"-Djava.util.logging.config.file=${env_var:UIMA_HOME}/config/Logger.properties"
-DVNS_HOST=localhost
Are we being hypocritical here, using environment variables in Java
when convenient but saying that others should not?
Eddie
On 4/12/07, Adam Lally <al...@alum.rpi.edu> wrote:
> I think it might not be so bad to have the <envVarRef> resolve first
> to a Java system property, if one exists, and if none exists then try
> to get an actual environment variable (if the underlying JRE supports
> it). Then at least existing applications that work will continue to
> work. The worst that might happen to an existing application is a
> case where the <envVarRef> resolved to empty string might suddently
> start picking up a value from the enviornment, but this seems very
> rare.
>
> Still, like Thilo I'm not entirely convinced that this feature is even
> a good idea at all. It's true we've had users ask for this, but I'm
> concerned that it complicates reusability of UIMA components. To
> deploy someone's component you now have yet another thing to worry
> about besides configuration parameter settings and external resource
> bindings - now you have to make sure the environment variables are set
> up right. (I suppose any particular annotator might access
> environment variables in its code anyway, so we can't entirely avoid
> that, but I'm reluctant to have UIMA actually encourage it).
>
> -Adam
>
> On 4/12/07, Thilo Goetz <tw...@gmx.de> wrote:
> > Marshall Schor wrote:
> > > Adam Lally wrote:
> > >> On 3/26/07, Thilo Goetz <tw...@gmx.de> wrote:
> > >>> I agree that people may be using it. I haven't seen it used in a while,
> > >>> but that doesn't mean anything. If we don't plan on removing the
> > >>> feature, why should we deprecate it?
> > >>>
> > >>> The name is because we wanted no difference between Java and C++
> > >>> descriptors. System properties are the way to do env vars in Java.
> > >>> System env vars are deprecated in Java. So I'd vote to leave things as
> > >>> they are. If the CDE doesn't support this (documented and I assume,
> > >>> working) feature, maybe we should add that support?
> > >>>
> > >>
> > >> BTW, System.getEnv is no longer deprecated in Java 5. But I'm not
> > >> sure that really helps us, since at present we're still committing to
> > >> support Java 1.4.
> > >>
> > >> -Adam
> > >>
> > >>
> > >
> > > In Java 1.4, although it's marked as deprecated, it is available. And
> > > it's no longer
> > > deprecated in Java 5 or Java 6. So we could change this to
> > > access environment variables directly, right? Then it would match the
> > > C++ impl.
> > >
> > > -Marshall
> > >
> >
> > Changing this might break backward compatibility in fairly subtle ways.
> > I'd be very careful to change the behavior of an existing feature in
> > that way. If we want to change it (it and I'm not at all convinced we
> > do), I'd vote for removing the <envVar> feature and replacing it with a
> > new one that has the desired properties. That will alert both annotator
> > writers and application developers to the change.
> >
> > --Thilo
> >
> >
> >
> >
>
Re: s in UIMA descriptors
Posted by Adam Lally <al...@alum.rpi.edu>.
I think it might not be so bad to have the <envVarRef> resolve first
to a Java system property, if one exists, and if none exists then try
to get an actual environment variable (if the underlying JRE supports
it). Then at least existing applications that work will continue to
work. The worst that might happen to an existing application is a
case where the <envVarRef> resolved to empty string might suddently
start picking up a value from the enviornment, but this seems very
rare.
Still, like Thilo I'm not entirely convinced that this feature is even
a good idea at all. It's true we've had users ask for this, but I'm
concerned that it complicates reusability of UIMA components. To
deploy someone's component you now have yet another thing to worry
about besides configuration parameter settings and external resource
bindings - now you have to make sure the environment variables are set
up right. (I suppose any particular annotator might access
environment variables in its code anyway, so we can't entirely avoid
that, but I'm reluctant to have UIMA actually encourage it).
-Adam
On 4/12/07, Thilo Goetz <tw...@gmx.de> wrote:
> Marshall Schor wrote:
> > Adam Lally wrote:
> >> On 3/26/07, Thilo Goetz <tw...@gmx.de> wrote:
> >>> I agree that people may be using it. I haven't seen it used in a while,
> >>> but that doesn't mean anything. If we don't plan on removing the
> >>> feature, why should we deprecate it?
> >>>
> >>> The name is because we wanted no difference between Java and C++
> >>> descriptors. System properties are the way to do env vars in Java.
> >>> System env vars are deprecated in Java. So I'd vote to leave things as
> >>> they are. If the CDE doesn't support this (documented and I assume,
> >>> working) feature, maybe we should add that support?
> >>>
> >>
> >> BTW, System.getEnv is no longer deprecated in Java 5. But I'm not
> >> sure that really helps us, since at present we're still committing to
> >> support Java 1.4.
> >>
> >> -Adam
> >>
> >>
> >
> > In Java 1.4, although it's marked as deprecated, it is available. And
> > it's no longer
> > deprecated in Java 5 or Java 6. So we could change this to
> > access environment variables directly, right? Then it would match the
> > C++ impl.
> >
> > -Marshall
> >
>
> Changing this might break backward compatibility in fairly subtle ways.
> I'd be very careful to change the behavior of an existing feature in
> that way. If we want to change it (it and I'm not at all convinced we
> do), I'd vote for removing the <envVar> feature and replacing it with a
> new one that has the desired properties. That will alert both annotator
> writers and application developers to the change.
>
> --Thilo
>
>
>
>
Re: s in UIMA descriptors
Posted by Thilo Goetz <tw...@gmx.de>.
Marshall Schor wrote:
> Adam Lally wrote:
>> On 3/26/07, Thilo Goetz <tw...@gmx.de> wrote:
>>> I agree that people may be using it. I haven't seen it used in a while,
>>> but that doesn't mean anything. If we don't plan on removing the
>>> feature, why should we deprecate it?
>>>
>>> The name is because we wanted no difference between Java and C++
>>> descriptors. System properties are the way to do env vars in Java.
>>> System env vars are deprecated in Java. So I'd vote to leave things as
>>> they are. If the CDE doesn't support this (documented and I assume,
>>> working) feature, maybe we should add that support?
>>>
>>
>> BTW, System.getEnv is no longer deprecated in Java 5. But I'm not
>> sure that really helps us, since at present we're still committing to
>> support Java 1.4.
>>
>> -Adam
>>
>>
>
> In Java 1.4, although it's marked as deprecated, it is available. And
> it's no longer
> deprecated in Java 5 or Java 6. So we could change this to
> access environment variables directly, right? Then it would match the
> C++ impl.
>
> -Marshall
>
Changing this might break backward compatibility in fairly subtle ways.
I'd be very careful to change the behavior of an existing feature in
that way. If we want to change it (it and I'm not at all convinced we
do), I'd vote for removing the <envVar> feature and replacing it with a
new one that has the desired properties. That will alert both annotator
writers and application developers to the change.
--Thilo