[jira] Created: (UIMA-374) CPE GUI left in bad state if you open a CPE descriptor that refers to a nonexistent component descriptor
CPE GUI left in bad state if you open a CPE descriptor that refers to a nonexistent component descriptor Key: UIMA-374 URL: https://issues.apache.org/jira/browse/UIMA-374 Project: UIMA Issue Type: Bug Components: Tools Affects Versions: 2.1 Reporter: Adam Lally Fix For: 2.2 In the CPE GUI choose "File -> Open Descriptor" and select an CPE descriptor that's invalid because one of its CAS Processor descriptor paths does not refer to a file that actually exists. And error will be dispalyed in the GUI will show as if the invalid component is not present. However, if you try to run the CPE now, you'll again get the error that the CAS Processor descriptor file does not exist. The invalid path is still there, but hidden, and there's no way to actually delete it, short of hand-editing the XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-371) XMI serialization to UIMA C++
[ https://issues.apache.org/jira/browse/UIMA-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bhavani Iyer updated UIMA-371: -- Attachment: uimacpp_xmi.zip uimacpp_xmi.patch The attached contains the implementation of C++ support for XMI serialization. the XMI code is a port of the XMI serialization code from the Apache Java distribution, combined with techniques used in XCAS serialization code from Apache C++ distribution. The patch contains fixes to the bugs listed below found while implementing the XMI serialization: a) removed assert statements which were preventing proper reporting of exceptions when loading an annotator dll which is not found in the path and on call to getIndex with an invalid index name. b) fixes to XMLParser methods to synch up with the schema. This is required for XMI test cases. c) Type name of ANNOTATION_BASE missing the namespace prefix. Fix required for XMI serialization to work properly. > XMI serialization to UIMA C++ > - > > Key: UIMA-371 > URL: https://issues.apache.org/jira/browse/UIMA-371 > Project: UIMA > Issue Type: New Feature > Components: C++ Framework >Reporter: Eddie Epstein > Assigned To: Eddie Epstein > Fix For: 2.2 > > Attachments: uimacpp_xmi.patch, uimacpp_xmi.zip > > > In order to comply to the UIMA standard for CAS data, Bhavani Iyer has been > working on XMI serialization support for UIMA C++. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-373) UIMA's Unix command line utilities are named badly
[ https://issues.apache.org/jira/browse/UIMA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488697 ] Adam Lally commented on UIMA-373: - Can we have both? I wouldn't want to disorient our users who had gotten used to the .sh versions. The extension-less command could just call the .sh version (or vice-versa) so there wouldn't have to be duplicate files to maintain. A symbolic link might be better, but I'm not sure how to do that and maintain a platform-independent built process. > UIMA's Unix command line utilities are named badly > -- > > Key: UIMA-373 > URL: https://issues.apache.org/jira/browse/UIMA-373 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework > Environment: Unix >Reporter: Eddie Epstein > > UIMA command line utilities are available in two flavors: commandName.bat for > Windows and commandName.sh for Unix. The Unix world typically does not use an > extension for scripts. > In addition to looking dumb, my real peeve with the .sh extension is how it > complicates writing documentation, saying things like "using the cpeGui shell > script (cpeGui.bat on Windows, cpeGui.sh on Unix)". Dropping .sh would allow > the documentation to just say "using commandName". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-373) UIMA's Unix command line utilities are named badly
[ https://issues.apache.org/jira/browse/UIMA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488682 ] Thilo Goetz commented on UIMA-373: -- Many people do in fact use .sh as script file extension, and it is considered a best practice by some. I don't personally like files without extensions very much, as it's even harder to know what they are. Don't you think we can expect our users to make the leap from "cpeGui shell script" cpeGui.bat or cpeGui.sh, depending on the platform? I think users who don't manage to make that connection by themselves will have a very hard time with the rest of UIMA. And while we're on the topic of "typically": command names typically don't use camel case. So there ;-) > UIMA's Unix command line utilities are named badly > -- > > Key: UIMA-373 > URL: https://issues.apache.org/jira/browse/UIMA-373 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework > Environment: Unix >Reporter: Eddie Epstein > > UIMA command line utilities are available in two flavors: commandName.bat for > Windows and commandName.sh for Unix. The Unix world typically does not use an > extension for scripts. > In addition to looking dumb, my real peeve with the .sh extension is how it > complicates writing documentation, saying things like "using the cpeGui shell > script (cpeGui.bat on Windows, cpeGui.sh on Unix)". Dropping .sh would allow > the documentation to just say "using commandName". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-373) UIMA's Unix command line utilities are named badly
UIMA's Unix command line utilities are named badly -- Key: UIMA-373 URL: https://issues.apache.org/jira/browse/UIMA-373 Project: UIMA Issue Type: Improvement Components: Core Java Framework Environment: Unix Reporter: Eddie Epstein UIMA command line utilities are available in two flavors: commandName.bat for Windows and commandName.sh for Unix. The Unix world typically does not use an extension for scripts. In addition to looking dumb, my real peeve with the .sh extension is how it complicates writing documentation, saying things like "using the cpeGui shell script (cpeGui.bat on Windows, cpeGui.sh on Unix)". Dropping .sh would allow the documentation to just say "using commandName". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: s in UIMA descriptors
On 4/13/07, Eddie Epstein <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote:
I think it might not be so bad to have the 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 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 <[EMAIL PROTECTED]> wrote:
> Marshall Schor wrote:
> > Adam Lally wrote:
> >> On 3/26/07, Thilo Goetz <[EMAIL PROTECTED]> 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 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
>
>
>
>
