[jira] Resolved: (UIMA-521) Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven
[ https://issues.apache.org/jira/browse/UIMA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-521. - Resolution: Fixed Assignee: Marshall Schor (was: Adam Lally) Fixed by updating the root uimaj pom.xml file. Assigned to Marshall to review since he pointed out the need for source jars to be published to Maven repo. > Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven > --- > > Key: UIMA-521 > URL: https://issues.apache.org/jira/browse/UIMA-521 > Project: UIMA > Issue Type: Task > Components: Build, Packaging and Test > Reporter: Adam Lally >Assignee: Marshall Schor > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-521) Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven
Add LICENSE, DISCLAIMER, and NOTICES files to source jars produced by Maven --- Key: UIMA-521 URL: https://issues.apache.org/jira/browse/UIMA-521 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Put Maven artifacts up for vote too?
On 8/7/07, Marshall Schor <[EMAIL PROTECTED]> wrote: > OK with me. I verified that in at least one Jar (and Adam should > confirm the build does this > for all Jars) there are the following files in the META-INF directory: > >DISCLAIMER >LICENSE >NOTICES > I check that these files are in all of the jars. For the Eclipse plugins, though, the DISCLAIMER, LICENSE, and NOTICE files are in the jars that are inside the plugin zip files, but they aren't in the META-INF directory of the plugins themselves. That might be a problem. > Maven has a the ability to download "sources" as well from the > repository, for Eclipse: > > |mvn -Declipse.downloadSources=true| > > This tells maven to download all associated sources of jar files in the > pom.xml. Amazing, how much easier it is to set up a project with proper > debugging sources etc. > > Do we need to do something to "enable" this to work? > Maven automatically generates "sources" jar files (check your local Maven repository). Unfortunately these don't have the DISCLAIMER, LICENSE, NOTICES. I will see if I can figure out how to get those to be added. -Adam
Re: Put Maven artifacts up for vote too?
On 8/7/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > Hi Adam, > > sure. Which jars do we want to publish? All of them, or the core > jar only? > I think all of them. I'm less certain though about the Eclipse plugins (where the Maven artifact is a zip, not a jar). I'll ask on uima-user in case there are people interested in this who don't also read uima-dev. > I also gave up on following the Maven debate on [EMAIL PROTECTED] at some > point. What repository are we allowed to deploy to? > /www/people.apache.org/repo/m2-incubating-repository That's according to a note from Dan Kulp 7 days ago on this subject. -Adam
Put Maven artifacts up for vote too?
As I recall we had a couple of user requests for us to publish our jars as Maven artifacts in the Apache incubator repository. And I think I got our Maven metadata into shape during the 2.1.0 release process after some comments from Dan Kulp on the [EMAIL PROTECTED] list. So should we put these up for a vote as well? -Adam
Re: [VOTE] Release uimaj-2.2.0-RC5 as uimaj-2.2.0-incubating
> The release artifacts are available on people.a.o at > /home/twgoetz/uima-distributions/2.2/RC5 > > So please cast your vote: > > [ ] +1 Release RC5, it's ready > [ ] -1 Don't release yet, I found issues > +1 Adam
Re: Make that RC5 [was: uimaj-2.2.0-RC4]
On 8/6/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > Thilo Goetz wrote: > > I built a new release candidate with Adam's and Marshall's fixes > > in. It's available as usual at on people.a.o at > > /home/twgoetz/uima-distributions/2.2/RC5. Let's try a new vote > > later today or tomorrow. > > Looks good. My functional test scripts all pass on this build. I see on the test plan Wiki page it still says (with bright orange background): "Noticing potential failure of "merging" code if JVM target > 1.4 - need fix in next release". Did that get addressed? If so we may want to update the Wiki. -Adam
Re: [VOTE] Release uimaj-2.2.0-RC4 as uimaj-2.2.0-incubating
On 8/3/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > I think we're finally ready ;-) I cut RC3 this morning, > found a minor issue with RAT and did RC4. Next time I'll > run RAT before tagging the release... > > The release artifacts are available on people.a.o at > /home/twgoetz/uima-distributions/2.2/RC4 > If somebody (other than me) could check the signatures, > that would be great. > I found an issue - the RELEASE_NOTES still say version 2.1.0 at the top. :( I will fix in SVN. -Adam
Re: Source in the binary release
> We should update the documentation (3 places?) which describes how to > attach javadocs, to now also mention > running those scripts to attach the source. > I updated the README file for the source distribution. Not sure where else we have documentation relating to the source dist - on the website? -Adam
Re: Source in the binary release
On 8/1/07, Michael Baessler <[EMAIL PROTECTED]> wrote: > I see that issue 499 is still in reopen state. I checked in my changes > using this issue. So I think we can close them or is there anything else > we need to do? OK with me to close it. -Adam
Re: Source in the binary release
On 7/31/07, Marshall Schor <[EMAIL PROTECTED]> wrote: > Also - the resources need to be included in the jars (they have the > message bundles, etc.). > The resource are already in the jars, so we don't need to add them in this step. Just the source files need to be added. -Adam
Re: Source in the binary release
> Actually I was thinking of something perhaps even easier for the user. > What I meant was that the script would automatically add the source > files directly into the jar files in the UIMA binary distribution. So > no action would be necessary at all in Eclipse. > > (To locate the binary distribution the script needs the UIMA_HOME > environment variable or could fall back on assuming that the source > dist. was instlled in the "src" subdirectory of the binary dist.) > I took a crack at implementing these scripts and have committed them to SVN. I put them in uimaj-distr/src/main/readme_src because this directory contains files that are copied to the root directory of the source distribution. Perhaps that directory should be renamed though. I updated the README file (also in readme_src) to explain what the scripts do. Let me know what you think. -Adam
Re: Source in the binary release
On 7/31/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > I don't want to put words into Adam's mouth, but at least I was thinking > that the script would just be part of our regular source distribution, > so no separate download required. And if the script lives in the source > distribution, it knows where the the source code is, so no path required. Yes that's what I was thinking too. > So the user calls the script, optionally copies the generated zip file > to the UIMA binary distribution, and proceeds as I already documented. Actually I was thinking of something perhaps even easier for the user. What I meant was that the script would automatically add the source files directly into the jar files in the UIMA binary distribution. So no action would be necessary at all in Eclipse. (To locate the binary distribution the script needs the UIMA_HOME environment variable or could fall back on assuming that the source dist. was instlled in the "src" subdirectory of the binary dist.) -Adam
Re: Are we ready to release 2.2?
On 7/30/07, Marshall Schor <[EMAIL PROTECTED]> wrote: > Except for needing to rerun the release note generation, I'm +1 ! for > doing the 2.2 release. > Thilo - if you agree, can you call for an official vote? > Thilo asked for a vote on whether to include the source in the binary distribution. I'm not opposed to holding that vote (though at present I'm still -1), but am still holding out hope we can find a compromise solution (see other thread). -Adam
Re: Source in the binary release
On 7/30/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > Adam Lally wrote: > >> -1 to this change. What exactly is the concern here? > > > > My main concern is what I originally said: "Don't some companies have > > issues with their people downloading source code?" > > Does that concern a large corporation that some of us work > for, or is this a known concern for other companies, too? > I only know the specifics for corporations that I happen to work for. :) Without knowing for sure that it *isn't* a problem for others, I think it's a risky move to eliminate our binary-only release. Addressing the convenience issue of dealing with our source release, could we whip up a script that would add the right source files to the right jar files? It wouldn't even need to compile anything so shouldn't have a dependency on anything but the "jar" command line tool. -Adam
Re: Source in the binary release
> -1 to this change. What exactly is the concern here? My main concern is what I originally said: "Don't some companies have issues with their people downloading source code?" > Source code? We're an open source project, after all. Well we do have a source release. What is the concern that led to bundling the source in the binary distribution? That people shouldn't have to do two separate downloads? We could have three separate releases - binary, source, and both. Not my preference, but preferable to not having a binary-only release at all. -Adam
Re: Suggestion for updating release notes automatically
On 7/29/07, Marshall Schor <[EMAIL PROTECTED]> wrote: > In our release notes, the last section is cut/pasted from the release > note generation done by Jira. We could replace that with a > link to the Jira system to (re)generate on demand the release notes. > The link would be, for instance for 2.2: > > http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312272&styleName=Html&projectId=12310570&Create=Create > http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12312272&styleName=Text&projectId=12310570&Create=Create > > for the html and text > > If we just put those links into our release notes the would always be up > to date :-). > > Is this a good idea? > Hmmm, I think it is nicer to have actual release notes bundled in the release... but I don't feel that strongly. I don't suppose there is some kind of SVN macro that, when you extract the file from the repository, automatically gets replaced by the contents of a URL. That would be cool... :) -Adam
[jira] Closed: (UIMA-514) remove souce jars from binary distribution
[ https://issues.apache.org/jira/browse/UIMA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-514. --- looks right to me > remove souce jars from binary distribution > -- > > Key: UIMA-514 > URL: https://issues.apache.org/jira/browse/UIMA-514 > Project: UIMA > Issue Type: Bug > Components: Build, Packaging and Test >Reporter: Michael Baessler > Assignee: Adam Lally > Fix For: 2.2 > > > We discussed the topic: > Don't some companies have issues with their people downloading source code in > the binary release? > Does this create a barrier for UIMA to be used?" > and we decided to remove the source jars from the binary distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-499) Add source jars to binary distribution
[ https://issues.apache.org/jira/browse/UIMA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-499: - > Add source jars to binary distribution > -- > > Key: UIMA-499 > URL: https://issues.apache.org/jira/browse/UIMA-499 > Project: UIMA > Issue Type: Improvement > Components: Build, Packaging and Test >Reporter: Thilo Goetz > Assignee: Adam Lally >Priority: Minor > Fix For: 2.2 > > > Adding source jars to our distribution will make programming against our APIs > a lot more convenient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-499) Make it easier for users to view UIMA JavaDocs from Eclipse
[ https://issues.apache.org/jira/browse/UIMA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-499: Fix Version/s: (was: 2.2) Summary: Make it easier for users to view UIMA JavaDocs from Eclipse (was: Add source jars to binary distribution) We decided against including source in our binary distribution. But it's still a valid concern to make it easier for Eclipse users to view the UIMA API JavaDocs. One idea is to make a New UIMA Project Wizard that could automatically set up a new project where the classpath contains all the UIMA jar files and the javadocs are attached. > Make it easier for users to view UIMA JavaDocs from Eclipse > --- > > Key: UIMA-499 > URL: https://issues.apache.org/jira/browse/UIMA-499 > Project: UIMA > Issue Type: Improvement > Components: Build, Packaging and Test >Reporter: Thilo Goetz >Assignee: Adam Lally >Priority: Minor > > Adding source jars to our distribution will make programming against our APIs > a lot more convenient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-473) Update README and RELEASE_NOTES
[ https://issues.apache.org/jira/browse/UIMA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-473: - need to redo release notes to remove issues related to the C++ framework > Update README and RELEASE_NOTES > --- > > Key: UIMA-473 > URL: https://issues.apache.org/jira/browse/UIMA-473 > Project: UIMA > Issue Type: Task > Components: Build, Packaging and Test > Reporter: Adam Lally > Assignee: Adam Lally > Fix For: 2.2 > > > Version numbers need updating. > "Major Changes in this Release" section of RELEASE_NOTES needs to be written > List of JIRA issues needs to be copied to RELEASE_NOTES > Be sure to update both RELEASE_NOTES and RELEASE_NOTES.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Source in the binary release
On 7/26/07, Michael Baessler <[EMAIL PROTECTED]> wrote: So should be add the source jars to the source release? I don't think that is the normal Apache thing to do. On http://incubator.apache.org/guides/releasemanagement.html it defines source release as "a simple export from the repository." I think putting derived artifacts in the source distribution should probably be avoided at least for the most part. We could consider having a third distribution which is like the binary distribution but also has source in the jar files. But OTOH there's a nice simplicity to having just two distributions - binary and source - to build, test, vote on, and post on our website for download. Do I get this right that this is mostly about making the javadocs available in Eclipse? Even people who don't want the source code might want that, so I think it would be nicer to find a different way to enable that. A thought: is it possible to have our Eclipse plugins define a "New UIMA Project" wizard that automatically creates a new project with all the right jar and javadoc references? -Adam
[jira] Closed: (UIMA-398) test case intermittently fails running Java 6 - with a hang: uimaj-core, org.apache.uima.analysis_engine.impl.MultiprocessingAnalysisEngine_implTest
[
https://issues.apache.org/jira/browse/UIMA-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally closed UIMA-398.
---
> test case intermittently fails running Java 6 - with a hang: uimaj-core,
> org.apache.uima.analysis_engine.impl.MultiprocessingAnalysisEngine_implTest
>
>
> Key: UIMA-398
> URL: https://issues.apache.org/jira/browse/UIMA-398
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
>Affects Versions: 2.1
> Environment: Sun Java 6_01
>Reporter: Marshall Schor
> Attachments: screenshot-1.jpg
>
>
> The failure is intermittent. It fails the first time running (for me) from a
> reboot, but runs after that. The failure occurs in the test where it does a
> threads[i].join(); and happens when i = 0. I found this out by changing the
> join() to join(1), and then inserting:
> if (threads[i].isAlive()) {
> System.err.println("timeout waiting for thread to complete " + i);
> fail("timeout waiting for thread to complete " + i);
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-496) PEAR API does not delete the PEAR ID subdirectory before the new content is installed
[ https://issues.apache.org/jira/browse/UIMA-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-496. --- > PEAR API does not delete the PEAR ID subdirectory before the new content is > installed > - > > Key: UIMA-496 > URL: https://issues.apache.org/jira/browse/UIMA-496 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Reporter: Michael Baessler >Assignee: Adam Lally > Fix For: 2.2 > > > When installing a PEAR file, currently the InstallationController API > overrides all available data in the target installation directory. The > directory content isn't removed before. So it can happen that old class files > or descriptor files that are never valid are still in the installation > directory since they will not be removed when the new stuff is installed. > Existing files with the same name will be overridden. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Updated release notes
The list of JIRA issues in the release notes was out of date. I have updated it. So we'll at least need a new build for that.
Source in the binary release
When checking through the Resolved issues assigned to me I noticed that one of them was the addition of jars containing our source code, as part of our binary release. I must have missed that when it went in. I'm a little uneasy about this. Don't some companies have issues with their people downloading source code? Does this create a barrier for UIMA to be used? What do other apache projects do here - is it common for binary distributions to contain the source? I think this perhaps deserves some discussion. -Adam
[jira] Closed: (UIMA-442) FileUtilsTest fail on Linux
[
https://issues.apache.org/jira/browse/UIMA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally closed UIMA-442.
---
> FileUtilsTest fail on Linux
> ---
>
> Key: UIMA-442
> URL: https://issues.apache.org/jira/browse/UIMA-442
> Project: UIMA
> Issue Type: Bug
> Components: Build, Packaging and Test
>Affects Versions: 2.1
> Environment: Ubuntu Linux 7.04- SUN Java 6 (1.6.0-b105), Eclipse
> 3.3RC3, Maven 2.0.6
>Reporter: Roberto Franchini
>Assignee: Adam Lally
> Fix For: 2.2
>
>
> The FileUtilsTest fails on linux while using windows path:
> base = new File("c:/foo/bar/baz/dir/");
> target = new File("c:/foo/d1/d2/d3/blah.xml");
> assertEquals("../../../d1/d2/d3/blah.xml",
> FileUtils.findRelativePath(target, base));
> Eclipse JUnit trace:
> junit.framework.ComparisonFailure: expected:<./../d1/d2/d3/...> but
> was:<...c:\foo\d1\d2\d3\...>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at
> org.apache.uima.util.FileUtilsTest.testFindRelativePath(FileUtilsTest.java:41)
> [snip]
> Maven fails too:
> ...
> Running org.apache.uima.util.FileUtilsTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec <<<
> FAILURE!
> ...
> Results :
> Failed tests:
> testFindRelativePath(org.apache.uima.util.FileUtilsTest)
> Tests run: 363, Failures: 1, Errors: 0, Skipped: 0
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-325) Enhance XMI Serializer to support merging multiple XMI documents into a single CAS
[ https://issues.apache.org/jira/browse/UIMA-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-325. --- > Enhance XMI Serializer to support merging multiple XMI documents into a > single CAS > -- > > Key: UIMA-325 > URL: https://issues.apache.org/jira/browse/UIMA-325 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework > Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > The new feature would support the following scenario: > 1) A CAS is serialized to XMI. > 2) Copies of the XMI documents are sent to multiple remote services > 3) Each remote service appends to the CAS (does not delete or modify > existing stuff) and responds with a new serialized XMI CAS) > 4) The multiple XMI responses are all merged back into a single CAS instance > This would permit multiple remote services that don't depend on each > other to run in parallel, assuming they only append to the CAS (which > is common). Of course there's other work on the runtime needed to > actually do the parallel invocations, but XMI serializer support is a > prerequisite. > The basic XMI deserializer changes aren't too complicated. First, > when the CAS is originally serialized in step 1, we make available to > the caller the maximum xmi:id value in that CAS (this is mostly > already done, we just need to add a public accessor for this value). > Next, we allow passing this value to the deserializer as an optional > argument that essentially says "deserialize only XMI elements whose > xmi:id is greater than the specified value". > Discussion here: > http://www.mail-archive.com/uima-dev@incubator.apache.org/msg02338.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-337) Should log process begin/end for service adapters
[ https://issues.apache.org/jira/browse/UIMA-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-337. --- > Should log process begin/end for service adapters > - > > Key: UIMA-337 > URL: https://issues.apache.org/jira/browse/UIMA-337 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.1 > Reporter: Adam Lally >Assignee: Adam Lally >Priority: Minor > Fix For: 2.2 > > > Users requests that service adapters (i.e. stubs for remote services) log > messages such as the "Analysis Engine process begin/end" that are > already logged for integrated AEs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-339) Support MBean Name Prefix in the additional parameters map passed to produceAE
[ https://issues.apache.org/jira/browse/UIMA-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-339. --- > Support MBean Name Prefix in the additional parameters map passed to produceAE > -- > > Key: UIMA-339 > URL: https://issues.apache.org/jira/browse/UIMA-339 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework > Reporter: Adam Lally > Assignee: Adam Lally > Fix For: 2.2 > > > This is desired for embedding a UIMA AE in an application that uses JMX. The > application should be able to specify a name that will be prefixed to all of > the MBean names that the AE generates. That way the application can control > how the UIMA MBeans are organized relative to the application's own MBeans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Docu update for UIMA-443 necessary
You might want to check out the documentation for capabilityLanguageFlow and see if you want to improve it. As I recall I thought the previous implementation (prior to the UIMA-443) was also consistent with the documentation, but there were some additional undocumented (or poorly documented) things that you wanted it to do. Otherwise I don't a need for further documentation. -Adam On 7/23/07, Michael Baessler <[EMAIL PROTECTED]> wrote: Hi Adam, I think you have fixed issue UIMA-443: fix flow ResultSpec handling... do we need to add anything to the documentation about this topic? I think the documentation now fits the implementation, do you agree? -- Michael
Re: svn commit: r557261 - /incubator/uima/uimaj/trunk/uima-docbooks/src/docbook/tutorials_and_users_guides/tug.cas_multiplier.xml
Looks fine to me. -Adam On 7/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: schor Date: Wed Jul 18 06:53:51 2007 New Revision: 557261 URL: http://svn.apache.org/viewvc?view=rev&rev=557261 Log: No Jira - tutorial example of CasCopier constructor had incorrect number of arguments. Adam - please check this example if you get a chance. Modified: incubator/uima/uimaj/trunk/uima-docbooks/src/docbook/tutorials_and_users_guides/tug.cas_multiplier.xml Modified: incubator/uima/uimaj/trunk/uima-docbooks/src/docbook/tutorials_and_users_guides/tug.cas_multiplier.xml URL: http://svn.apache.org/viewvc/incubator/uima/uimaj/trunk/uima-docbooks/src/docbook/tutorials_and_users_guides/tug.cas_multiplier.xml?view=diff&rev=557261&r1=557260&r2=557261 == --- incubator/uima/uimaj/trunk/uima-docbooks/src/docbook/tutorials_and_users_guides/tug.cas_multiplier.xml (original) +++ incubator/uima/uimaj/trunk/uima-docbooks/src/docbook/tutorials_and_users_guides/tug.cas_multiplier.xml Wed Jul 18 06:53:51 2007 @@ -712,7 +712,9 @@ mDocBuf.append(docText); // copy specified annotation types -CasCopier copier = new CasCopier(mMergedCas.getCas()); +// CasCopier takes two args: the CAS to copy from. +// the CAS to copy into. +CasCopier copier = new CasCopier(aJCas.getCas(), mMergedCas.getCas()); // needed in case one annotation is in two indexes (could // happen if specified annotation types overlap)
Re: [jira] Updated: (UIMA-458) For creating new UIMA descriptors in Eclipse, make accelerator keys work better
On 7/17/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: I wonder: is it a good idea to change the "affects version" label for these issues? I mean, they do affect 2.1, and since they haven't been fixed it's reasonable to assume that they affect 2.2 also. Is there an advantage to changing this? I think you can actually select multiple versions for the "Affects Version/s" label. So I definitely wouldn't remove 2.1. As to whether it's worth the effort to add 2.2, it might make sense to do this to support using the JIRA search to search for issues affecting a particular version. I'm assuming JIRA doesn't do the inference that unresolved issues affecting 2.1 also affect 2.2. -Adam
[jira] Commented: (UIMA-498) TAEConfiguratorPlugin throws NullPointer during activation
[ https://issues.apache.org/jira/browse/UIMA-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513246 ] Adam Lally commented on UIMA-498: - Any 3.0-compatibility stuff can be dropped completely now. We decided to drop support for 3.0 and have rewritten our plugin manifests in the 3.1+ style. > TAEConfiguratorPlugin throws NullPointer during activation > -- > > Key: UIMA-498 > URL: https://issues.apache.org/jira/browse/UIMA-498 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Affects Versions: 2.2 >Reporter: Jörn Kottmann > Fix For: 2.2 > > > TAEConfiguratorPlugin throws a NPE during activation if the > org.eclipse.platform plugin > is missing (but its not required <- not listed in manifest). > The plugin tries to retrieve the version of the org.eclipse.platform plugin > I suggest to remove the code since the version is not used after retrieval. > The code in question is located in the static initializer of the class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: multi-threading and TypeSystemImpl
On 7/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: >> :-) So the whole concept is useless. Remind me why we >> have parametric arrays? >> > Two uses currently: One is XMI serialization - it makes use of this > info for a much more compact serialized form. The second: JCasGen uses > this info when generating cover functions to do compile-time checking of > arguments, and returning the right class of result. So, if you have an > FSArray of Foo objects, defined as the type:feature MyType:FooArray, the > setters and getters for elements of this type, > anInstanceOfMyType.setFooArray(index, value) has the method parameter > type for "value" be of class Foo, rather than of class Top, and > anInstanceOfMyType.getFooArray(index) returns an instance of Foo class. > Shouldn't we have this capability on the regular CAS as well, then? Sure, but how should we proceed? The current state of things is that type system descriptors can specify an for an array-valued feature, for example: annotationArray uima.cas.FSArray uima.tcas.Annotation JCAS and XMI serialization essentially just treat this as metadata attached to the feature. There are never actually any instances of the parameterized array object. Partly the idea was that people could just document the elementTypes that they were currently implicitly using, and the wouldn't have to change their code. (In some ways this sort of reminds me of the Java 5 generics.) This is why subsumes is the way that it is. It allows assigning a "plain" FSArray to a feature with range type uima.tcas.Annotation[]. It would not be good to change this subsumes behavior now. A possible way out if we want to implement real parameterized arrays is for people to declare the feature with the square-bracket array notation: annotationArray uima.tcas.Annotation[] This would then not allow you to assign a plain FSArray to this feature. For the current users of we can make this really be just metadata attached to the Feature, rather than impacting the actual range type of the feature, and existing code should not break. But then there's all the implications of creating new Types after the TypeSystem is "locked", which we need to think through. For 2.2 I am in favor of deprecating getArrayType() since it is not-useful as-is, and possibly un-deprecating it in 2.3 after the whole parameterized array thing works the way we want it to. -Adam
Re: multi-threading and TypeSystemImpl
On 7/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: What's unclear about this method? You can get a Type object that represents a typed-array, but there is no way to create an instance of such an array. What good is it then to get the Type object? -Adam Adam Lally wrote: > On 7/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: >> Before we start deprecating methods, though, I would prefer it if we >> sat down and thought the whole array story through. What we have now >> could certainly use improvement, but I would like to understand what >> the real design is that we're aiming at. > > I think it is okay to deprecate first and understand later. A method > that we don't understand all the implications of and which we may want > to change later is a good one to discourage users from using today. > > -Adam
Re: multi-threading and TypeSystemImpl
On 7/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: Before we start deprecating methods, though, I would prefer it if we sat down and thought the whole array story through. What we have now could certainly use improvement, but I would like to understand what the real design is that we're aiming at. I think it is okay to deprecate first and understand later. A method that we don't understand all the implications of and which we may want to change later is a good one to discourage users from using today. -Adam
Re: multi-threading and TypeSystemImpl
On 7/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote: 4) I think we want to design the TypeSystemImpl so that when it is "locked" - it is thread-safe for running with multiple threads. This seems to involve adding synchronization to other object accesses. (Example object: the "locked" boolean). Because of (2) above, I'm guessing (hoping) this would not have an impact on performance. Assuming for a second that "locked" really meant that the type system didn't change, it seems like there should be some more efficient way to do this. A thread could synchronize briefly on the TypeSystem once when it first begins to process a CAS (just to make sure there is a "write barrier" so the thread really sees all the changes done prior to the locking), and thereafter it does not need to synchronize every time it wants to query anything. Even without much contention for the lock, synchronization adds some overhead. I guess I've heard this is a lot less in recent JRE versions than it used to be, but I still worry. However, given the situation with the array types allowed to be created after the type system is locked, this gets a lot more complicated. I'm not sure there's any good way to do it other than to stop creating new types after the type system is locked. Like you said, Marshall, the framework itself never does this, but exposes a public method that could. Maybe we need to deprecate that method? -Adam
Re: PEAR InstallationController API
Michael Baessler wrote: > Hi, > > when installing a PEAR file, currently the InstallationController API > overrides all available data in the target installation directory. The > directory content isn't removed before. > So it can happen that old class files or descriptor files that are > never valid are still in the installation directory since they will > not be removed when the new stuff is installed. Existing files with > the same name will be overridden. > > So my plan was to clean the target installation directory before the > new PEAR file is installed to it. If the target install directory > should be cleaned can be specified with an additional parameter when > using the PEAR installer API. > > An known issue with that approach is, that after installing a PEAR > file to a directory, the same PEAR file cannot be installed again to > the same directory with the same JVM since the JVM has locked the jars > so they cannot be deleted when the directory for the next installation > should be cleaned. To do that, the JVM must be restarted, or another > installation directory must be used. The JVM locks the jar files when > the installation verification is executed. > > What do others think about this approach? > Seems fine. Just to clarify - the PEAR file is always installed into a directory whose name is the PEAR's ID, and it's that directory which you will remove? So there's not a risk of the user accidentally deleting other files? -Adam
Re: July UIMA Board report due tomorrow - I put something in the wiki
Looks good. Thanks, Marshall. -Adam On 7/10/07, Marshall Schor <[EMAIL PROTECTED]> wrote: Please review and fix / augment as needed :-) Wiki is: http://wiki.apache.org/incubator/July2007 -Marshall
[jira] Closed: (UIMA-494) AnalysisEngineDescription_impl indirectly uses promletatic method URL.equals()
[ https://issues.apache.org/jira/browse/UIMA-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-494. --- Resolution: Fixed > AnalysisEngineDescription_impl indirectly uses promletatic method URL.equals() > -- > > Key: UIMA-494 > URL: https://issues.apache.org/jira/browse/UIMA-494 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 > Reporter: Adam Lally >Assignee: Adam Lally >Priority: Minor > Fix For: 2.2 > > > This class uses a Set containing URL objects, which will cause URL.equals() > to be called. URL.equals has performance problems since it can go out to the > internet to do domain name resolution. (In practice though, in our case the > URLs are almost always file URLs on the local machine.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-494) AnalysisEngineDescription_impl indirectly uses promletatic method URL.equals()
AnalysisEngineDescription_impl indirectly uses promletatic method URL.equals() -- Key: UIMA-494 URL: https://issues.apache.org/jira/browse/UIMA-494 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.2 This class uses a Set containing URL objects, which will cause URL.equals() to be called. URL.equals has performance problems since it can go out to the internet to do domain name resolution. (In practice though, in our case the URLs are almost always file URLs on the local machine.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CAS Merger question
FYI I responded to this thread on uima-user since that seemed the more appropriate forum. -Adam On 7/10/07, Benjamin Sznajder <[EMAIL PROTECTED]> wrote: Hi Eddie, Nice to read you ! When you say that, do you mean that I need to write a full new FlowController? Or, is it sufficient to override some parameter in a XML descriptor file? Regards, Benjamin "Eddie Epstein" <[EMAIL PROTECTED] com> To uima-dev@incubator.apache.org 10/07/2007 16:21 cc Subject Please respond to Re: CAS Merger question [EMAIL PROTECTED] r.apache.org On 7/10/07, Benjamin Sznajder <[EMAIL PROTECTED]> wrote: > The hasNext() method returns false when the CASMerger did not finish to > "merge". > When the hasNext() method returns false, then the inputted CAS passes to > the CASConsumer. I expected that no CAS is outputted until hasNext() > returns true. > > Is it the wished behavior? Hi Benjamin, This behavior of the built-in flow controller is designed to demonstrate a segmenting Cas multiplier at the front of an aggregate. It is not intended for all circumstances, and of course you can replace this code to achieve other behaviors. Eddie
[jira] Closed: (UIMA-489) Windows .bat files should use "endlocal" command
[ https://issues.apache.org/jira/browse/UIMA-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-489. --- Resolution: Cannot Reproduce I actually can't reproduce the described effect (which was reported to me by Lev Kozakov) - and Lev told me that endlocal did not help him anyway. > Windows .bat files should use "endlocal" command > > > Key: UIMA-489 > URL: https://issues.apache.org/jira/browse/UIMA-489 > Project: UIMA > Issue Type: Bug > Components: Build, Packaging and Test >Affects Versions: 2.1 > Reporter: Adam Lally >Assignee: Adam Lally >Priority: Minor > Fix For: 2.2 > > > We use "setlocal" in our scripts, but without "endlocal" this does not > prevent the environment set in the scripts from being exported to the command > console that called the script. This can result on the UIMA_CLASSPATH > variable growing longer and longer, and eventually in a "line to long" error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-476) FSArray causes error in SOAP service
On 7/5/07, Marshall Schor <[EMAIL PROTECTED]> wrote: Adam - can you look at Ecore2UimaTypeSystem and see if the "isArrayOrList" method would need updating? It looks correct, actually. Since this is converting from an Ecore model to a UIMA type system, it is in complete control of how the range type names are generated. And it generates them in the style expected in the component descriptor (which is what it ultimately generates). In that style the
[jira] Closed: (UIMA-413) Allow RunAE to use XMI format XML CAS for input and output
[ https://issues.apache.org/jira/browse/UIMA-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-413. --- Resolution: Fixed > Allow RunAE to use XMI format XML CAS for input and output > -- > > Key: UIMA-413 > URL: https://issues.apache.org/jira/browse/UIMA-413 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Eddie Epstein > Assignee: Adam Lally > Fix For: 2.2 > > > RunAE is a key test/development tool for annotators. It accepts input as raw > text or XCAS format files. It should support XMI format files as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-491) CPE GUI doesn't handle spaces in component descriptor file paths
[ https://issues.apache.org/jira/browse/UIMA-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-491. --- Resolution: Fixed > CPE GUI doesn't handle spaces in component descriptor file paths > > > Key: UIMA-491 > URL: https://issues.apache.org/jira/browse/UIMA-491 > Project: UIMA > Issue Type: Bug > Components: Tools >Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > This was introduced in supporting import in CPE descriptors. There's a > conversion to a URI that's not escaping spaces in the file paths. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-491) CPE GUI doesn't handle spaces in component descriptor file paths
[ https://issues.apache.org/jira/browse/UIMA-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-491: --- Assignee: Adam Lally > CPE GUI doesn't handle spaces in component descriptor file paths > > > Key: UIMA-491 > URL: https://issues.apache.org/jira/browse/UIMA-491 > Project: UIMA > Issue Type: Bug > Components: Tools >Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > This was introduced in supporting import in CPE descriptors. There's a > conversion to a URI that's not escaping spaces in the file paths. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-491) CPE GUI doesn't handle spaces in component descriptor file paths
CPE GUI doesn't handle spaces in component descriptor file paths Key: UIMA-491 URL: https://issues.apache.org/jira/browse/UIMA-491 Project: UIMA Issue Type: Bug Components: Tools Reporter: Adam Lally Fix For: 2.2 This was introduced in supporting import in CPE descriptors. There's a conversion to a URI that's not escaping spaces in the file paths. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-489) Windows .bat files should use "endlocal" command
Windows .bat files should use "endlocal" command Key: UIMA-489 URL: https://issues.apache.org/jira/browse/UIMA-489 Project: UIMA Issue Type: Bug Components: Build, Packaging and Test Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Priority: Minor Fix For: 2.2 We use "setlocal" in our scripts, but without "endlocal" this does not prevent the environment set in the scripts from being exported to the command console that called the script. This can result on the UIMA_CLASSPATH variable growing longer and longer, and eventually in a "line to long" error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-413) Allow RunAE to use XMI format XML CAS for input and output
[ https://issues.apache.org/jira/browse/UIMA-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-413: Fix Version/s: 2.2 > Allow RunAE to use XMI format XML CAS for input and output > -- > > Key: UIMA-413 > URL: https://issues.apache.org/jira/browse/UIMA-413 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Eddie Epstein > Assignee: Adam Lally > Fix For: 2.2 > > > RunAE is a key test/development tool for annotators. It accepts input as raw > text or XCAS format files. It should support XMI format files as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (UIMA-413) Allow RunAE to use XMI format XML CAS for input and output
[ https://issues.apache.org/jira/browse/UIMA-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reopened UIMA-413: - Assignee: Adam Lally (was: Eddie Epstein) For backwards compatibility should still accept the setting of the XCAS parameter to "true", meaning the same thing as if it were set to "xcas". > Allow RunAE to use XMI format XML CAS for input and output > -- > > Key: UIMA-413 > URL: https://issues.apache.org/jira/browse/UIMA-413 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Eddie Epstein >Assignee: Adam Lally > > RunAE is a key test/development tool for annotators. It accepts input as raw > text or XCAS format files. It should support XMI format files as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-476) FSArray causes error in SOAP service
[ https://issues.apache.org/jira/browse/UIMA-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-476: Fix Version/s: 2.2 I think we plan on fixing this for 2.2 > FSArray causes error in SOAP service > > > Key: UIMA-476 > URL: https://issues.apache.org/jira/browse/UIMA-476 > Project: UIMA > Issue Type: Bug > Components: Transport Adapters - SOAP, Vinci >Affects Versions: 2.1 > Environment: UIMA 2.1 and previous versions >Reporter: Yoshinobu KANO > Fix For: 2.2 > > > When we run a SOAP service with any type system which uses FSArray, > AnalysisEngineProcessException occurs, > though the same component can be run as a local service. > It occurs in the type system checking, independently of the component > implementations. > The error says: > Caused by: org.apache.uima.UIMARuntimeException: The JCas cannot be > initialized. The following errors occurred: The JCAS range type > uima.cas.FSArray for feature of type does > not match the CAS range [] for the feature. > # replaced our specific feature/type names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-480) DocumentAnalyzer interactive mode only eligible if an input data directory is specified
[ https://issues.apache.org/jira/browse/UIMA-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-480. - Resolution: Fixed Assignee: Michael Baessler (was: Adam Lally) I think I've fixed this - please review. > DocumentAnalyzer interactive mode only eligible if an input data directory is > specified > --- > > Key: UIMA-480 > URL: https://issues.apache.org/jira/browse/UIMA-480 > Project: UIMA > Issue Type: Bug > Components: Tools >Reporter: Michael Baessler >Assignee: Michael Baessler >Priority: Minor > Fix For: 2.2 > > > The DocumentAnalyzer interactive mode is only eligible if an input data > directory is specified. When I enter my own text why do I need to specify an > input directory? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Problems when running Junit test with Maven
Hmmm, haven't checked it, but I seem to recall that Maven uses some namng heuristics to decide what classes to execute. I think class names have to begin or end with "test" in order to be executed. Possibly, methods might also have to begin or end with "test" - I'm not sure. So that's something to look for. -Adam On 7/4/07, Michael Baessler <[EMAIL PROTECTED]> wrote: Hi, I just figured out that when I run our UIMA JUnit tests with Maven from the command line, not all tests are executed. Some of the test classes are not executed. For example in the uimaj-cpe project in my eclipse workspace I have 71 tests but when running maven from the command line I only see 34 executed test cases. The same with uimaj-core there I see 373 tests in eclipse but only 371 with Maven on the command line. Does anyone else see that behavior? -- Michael
[jira] Commented: (UIMA-473) Update README and RELEASE_NOTES
[ https://issues.apache.org/jira/browse/UIMA-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510014 ] Adam Lally commented on UIMA-473: - I rewrote the section on JCAS ClassLoading support. It could use some other eyes on it, though, since it's not an easy thing to describe. Mainly I tried to give the impression that the real change had to do with supporting multiple different ClassLoaders within the same JCAS. Previously, a single custom ClassLoader would work OK (it was not accurate to say that the framework's class loader was used for cover classes - the UIMA extension class loader would be used). It just wasn't possible to have multiple different ClassLoaders in use at the same time. Also I added a section to the Major Changes advertising that CPE descriptors now support . I know several people who really want that. > Update README and RELEASE_NOTES > --- > > Key: UIMA-473 > URL: https://issues.apache.org/jira/browse/UIMA-473 > Project: UIMA > Issue Type: Task > Components: Build, Packaging and Test >Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > Version numbers need updating. > "Major Changes in this Release" section of RELEASE_NOTES needs to be written > List of JIRA issues needs to be copied to RELEASE_NOTES > Be sure to update both RELEASE_NOTES and RELEASE_NOTES.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-328) CDE - handle case of searching for impl Java class, but the project is not a Java project
[ https://issues.apache.org/jira/browse/UIMA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-328: Fix Version/s: (was: 2.2) Affects Version/s: 2.2 Removed from 2.2 release as Marshall suggested on uima-dev > CDE - handle case of searching for impl Java class, but the project is not a > Java project > - > > Key: UIMA-328 > URL: https://issues.apache.org/jira/browse/UIMA-328 > Project: UIMA > Issue Type: Improvement > Components: Eclipse plugins >Affects Versions: 2.1, 2.2 >Reporter: Marshall Schor >Assignee: Marshall Schor >Priority: Trivial > > The CDE allows picking a Java implementation class for a primitive annotator. > The pick list is generated done using the Eclipse "Search" mechanism, which > is set up to search along the classes visible in the classpath to that > project. However, if the user puts their XML descriptor into a separate > project, which is not a Java project, then this strategy throws an > "unexpected exception". Change this behavior so that if the XML descriptor > is in a non-Java project, have the Search search the entire workspace for > candidate impl classes, to generate the pick list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-219) Clean up XCASSerializer code to remove what's left of Sofa mapping support
[ https://issues.apache.org/jira/browse/UIMA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-219: Fix Version/s: (was: 2.2) Priority: Trivial (was: Minor) Removed from 2.2 release as I suggested on uima-dev. Also downgraded priority, as this is only a code-cleanup issue. > Clean up XCASSerializer code to remove what's left of Sofa mapping support > -- > > Key: UIMA-219 > URL: https://issues.apache.org/jira/browse/UIMA-219 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Adam Lally >Assignee: Eddie Epstein >Priority: Trivial > > Clean up XCASSerializer code to remove Sofa mappings. This doesn't work > correctly, and is never used anyway -- the service adapters have been changed > to check for the use of sofa mapping and throw an exception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-474) Log messages for duplicate resource declarations have their arguments switched
[
https://issues.apache.org/jira/browse/UIMA-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally closed UIMA-474.
---
Resolution: Fixed
> Log messages for duplicate resource declarations have their arguments switched
> --
>
> Key: UIMA-474
> URL: https://issues.apache.org/jira/browse/UIMA-474
> Project: UIMA
> Issue Type: Bug
> Components: Core Java Framework
> Reporter: Adam Lally
> Assignee: Adam Lally
> Fix For: 2.2
>
>
> If you declare two resources with the same name, you get a log message:
> The external resource named {0} has been declared multiple times with
> different definitions. \
> The definition of the resource in component {1} will be used. The
> definition in component {2} will be ignored.
> However the code that generates the message has the arguments {1} and {2} the
> wrong way around, actualy it is the resource declared in component {2} that
> will be used.
> The same is true for the log message about overriding resources - it tells
> you that the resource declared in the aggregate was overriden by its
> delegate, which is the opposite of what actually happens.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-474) Log messages for duplicate resource declarations have their arguments switched
Log messages for duplicate resource declarations have their arguments switched
--
Key: UIMA-474
URL: https://issues.apache.org/jira/browse/UIMA-474
Project: UIMA
Issue Type: Bug
Components: Core Java Framework
Reporter: Adam Lally
Assignee: Adam Lally
Fix For: 2.2
If you declare two resources with the same name, you get a log message:
The external resource named {0} has been declared multiple times with different
definitions. \
The definition of the resource in component {1} will be used. The definition
in component {2} will be ignored.
However the code that generates the message has the arguments {1} and {2} the
wrong way around, actualy it is the resource declared in component {2} that
will be used.
The same is true for the log message about overriding resources - it tells you
that the resource declared in the aggregate was overriden by its delegate,
which is the opposite of what actually happens.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 2.2 release
On 6/26/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: Please take a look at the test plan, if you haven't done so already. There's a table with all the issues we wanted to fix for 2.2. You can add the documentation status of those issues there. Maybe for the next release, we could configure our Jira to have a column for that? It might be easier to track this all in one place. Thoughts? I took care of the documentation for the issues assigned to me and updated the status approprately. I also added my name under the test scenarios that I plan to do. I have the test cases set up for these so it makes sense that I continue to do them. -Adam
[jira] Created: (UIMA-473) Update README and RELEASE_NOTES
Update README and RELEASE_NOTES --- Key: UIMA-473 URL: https://issues.apache.org/jira/browse/UIMA-473 Project: UIMA Issue Type: Task Components: Build, Packaging and Test Reporter: Adam Lally Fix For: 2.2 Version numbers need updating. "Major Changes in this Release" section of RELEASE_NOTES needs to be written List of JIRA issues needs to be copied to RELEASE_NOTES Be sure to update both RELEASE_NOTES and RELEASE_NOTES.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.2 release
On 6/26/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: Hi all, according to our test plan (http://cwiki.apache.org/UIMA/testplan22.html), we have entered testing for our 2.2 release. We currently have the following issues tagged as "fix for 2.2" in Jira: UIMA-387 XMI Serializer can write invalid control characters UIMA-219 Clean up XCASSerializer code to remove what's left of Sofa mapping support UIMA-258 improve names of the UIMA documentation PDF files UIMA-328 CDE - handle case of searching for impl Java class, but the project is not a Java project UIMA-307 Fix CVD screenshots UIMA-219 is just code cleanup and isn't critical to get done for this release. -Adam
[jira] Resolved: (UIMA-465) Need getViewIterator() method to work with a variable number of views
[ https://issues.apache.org/jira/browse/UIMA-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-465. - Resolution: Fixed Assignee: Eddie Epstein (was: Adam Lally) Done. Eddie, please review. > Need getViewIterator() method to work with a variable number of views > - > > Key: UIMA-465 > URL: https://issues.apache.org/jira/browse/UIMA-465 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.2 >Reporter: Eddie Epstein >Assignee: Eddie Epstein > Fix For: 2.2 > > > Based on user feedback, a common design pattern is for an annotator to want > to process a set of Views in a CAS. Currently user code can do this using > getSofaIterator() and testing each SofaFS to see if it matches the > requirement. A simpler approach is to have a new method: > Iterator getViewIterator(viewname) > where viewname represents a Sofa name prefix. As with Sofa mapping, this API > would return all views with names matching viewname.*. Sofa mapping would be > respected, so "viewname" could be mapped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-465) Need getViewIterator() method to work with a variable number of views
[ https://issues.apache.org/jira/browse/UIMA-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-465: --- Assignee: Adam Lally > Need getViewIterator() method to work with a variable number of views > - > > Key: UIMA-465 > URL: https://issues.apache.org/jira/browse/UIMA-465 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.2 >Reporter: Eddie Epstein >Assignee: Adam Lally > Fix For: 2.2 > > > Based on user feedback, a common design pattern is for an annotator to want > to process a set of Views in a CAS. Currently user code can do this using > getSofaIterator() and testing each SofaFS to see if it matches the > requirement. A simpler approach is to have a new method: > Iterator getViewIterator(viewname) > where viewname represents a Sofa name prefix. As with Sofa mapping, this API > would return all views with names matching viewname.*. Sofa mapping would be > respected, so "viewname" could be mapped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-465) Need getViewIterator() method to work with a variable number of views
[ https://issues.apache.org/jira/browse/UIMA-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-465: Fix Version/s: 2.2 > Need getViewIterator() method to work with a variable number of views > - > > Key: UIMA-465 > URL: https://issues.apache.org/jira/browse/UIMA-465 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Affects Versions: 2.2 >Reporter: Eddie Epstein >Assignee: Adam Lally > Fix For: 2.2 > > > Based on user feedback, a common design pattern is for an annotator to want > to process a set of Views in a CAS. Currently user code can do this using > getSofaIterator() and testing each SofaFS to see if it matches the > requirement. A simpler approach is to have a new method: > Iterator getViewIterator(viewname) > where viewname represents a Sofa name prefix. As with Sofa mapping, this API > would return all views with names matching viewname.*. Sofa mapping would be > respected, so "viewname" could be mapped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-467) TypeSystemUtils.typeSystem2TypeSystemDescription produces invalid output for arrays with elementType specified
[ https://issues.apache.org/jira/browse/UIMA-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-467. --- Resolution: Fixed > TypeSystemUtils.typeSystem2TypeSystemDescription produces invalid output for > arrays with elementType specified > -- > > Key: UIMA-467 > URL: https://issues.apache.org/jira/browse/UIMA-467 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > User reports: if CAS was created from a TypeSystem Descriptor containing a > feature such as: > > compensationArray > > uima.cas.FSArray > uima.tcas.Annotation > > If you use TypeSystemUtil.typeSystem2TypeSystemDescription to generate a new > TypeSystem descriptor from this, it will look like: > > compensationArray > > uima.tcas.Annotation[] > > If you try to create a new CAS fromt his descriptor it will fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-467) TypeSystemUtils.typeSystem2TypeSystemDescription produces invalid output for arrays with elementType specified
TypeSystemUtils.typeSystem2TypeSystemDescription produces invalid output for arrays with elementType specified -- Key: UIMA-467 URL: https://issues.apache.org/jira/browse/UIMA-467 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Reporter: Adam Lally Assignee: Adam Lally Fix For: 2.2 User reports: if CAS was created from a TypeSystem Descriptor containing a feature such as: compensationArray uima.cas.FSArray uima.tcas.Annotation If you use TypeSystemUtil.typeSystem2TypeSystemDescription to generate a new TypeSystem descriptor from this, it will look like: compensationArray uima.tcas.Annotation[] If you try to create a new CAS fromt his descriptor it will fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-395) TypeSystemMgr.addFeature should default multipleReferencesAllowed argument to false.
[ https://issues.apache.org/jira/browse/UIMA-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-395: Fix Version/s: (was: 2.2) not necessary to figure this out for 2.2, as this isn't exposed to users at all > TypeSystemMgr.addFeature should default multipleReferencesAllowed argument to > false. > > > Key: UIMA-395 > URL: https://issues.apache.org/jira/browse/UIMA-395 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Adam Lally >Priority: Trivial > > This isn't a problem exposed to users, but is confusing for developers. > In the type system descriptor, the default value for > multipleReferencesAllowed is false. However, in the internal API > TypeSystemMgr.addFeature, the default is true. I think that default should > be changed to false to be consistent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-443) fix flow ResultSpec handling
[ https://issues.apache.org/jira/browse/UIMA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally resolved UIMA-443. - Resolution: Fixed Assignee: Michael Baessler (was: Adam Lally) I believe I've fixed this. I added a test case based on the example Michael posted to uima-dev. Michael, please double-check. > fix flow ResultSpec handling > > > Key: UIMA-443 > URL: https://issues.apache.org/jira/browse/UIMA-443 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Michael Baessler >Assignee: Michael Baessler > Fix For: 2.2 > > > Currently it is possible to set a result spec for a flow node > AnalysisSequenceCapabilityNode.setResultSpec(). But it seems that this > feature is never supported in UIMA 2.x. We should either remove/deprecate > this APIs if this is really true that it is never supported. > But I think that this was a very important feature for search engine > integrations, so I would vote for adding this functionality again to the > FlowController stuff. Let's start the discussion on how this can be done and > what we will do for UIMA 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-463) Can't find org.apache.uima.examples.xmi
Yes, it's intentional that the default classpath for uimaj-examples contains all the UIMA jars _except_ uimaj-examples.jar. That's because Eclipse should be picking up those classes from the source code in your workspace, so it shouldn't need that jar. It is strange that this is not working for you. A couple more questions" 1) Does the classpath (for example for the CPE GUI run configuration that you looked at) also contain an entry for "uimaj-examples" itself (with a folder icon)? This is what should be picking up the classes from your workspace. 2) If you expand the uimaj-examples project in your workspace, can you locate the "org.apache.uima.examples.xmi" package (and the other classes you're missing) under the "src" directory? 3) If you can find the source files, can you also find the corresponding class files under the "bin" directory (using the eclipse Navigator view or your file system explorer - the Package Explorer doesn't show them). If you can't find these, Eclipse must not be compiling the source for some reason. -Adam On 6/21/07, Andrew Borthwick <[EMAIL PROTECTED]> wrote: I don't see anything in Eclipse "problems". Note that I see uima-core.jar, uima-documentation-annotation,jar, etc. listed under the "default classpath" when I look at the classpath for the UIMA CPE GUI (via Run | Run ... | UIMA CPE GUI | Classpath). When I added [UIMA-HOME]/lib/UIMA-Examples.jar to the classpath listed here, it worked. Regards, Andrew On 6/21/07, Adam Lally (JIRA) wrote: > > [ https://issues.apache.org/jira/browse/UIMA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506895 ] > > Adam Lally commented on UIMA-463: > - > > Hmm, it shouldn't be necessary to add uimaj-examples.jar to the classpath for the uimaj-examples project, because the source code for the examples should be in the uimaj-examples project itself. So Eclipse should compile it and make those classes available in your project classpath. > > Can you check the Eclipse "Problems" view and see if it lists any compilation errors? > > > Can't find org.apache.uima.examples.xmi > > --- > > > > Key: UIMA-463 > > URL: https://issues.apache.org/jira/browse/UIMA-463 > > Project: UIMA > > Issue Type: Bug > > Components: Examples > > Environment: Eclipse 3.2.2, ubuntu linux 7.04, JRE: java-1.5.0-sun-1.5.0.11 > >Reporter: Andrew Borthwick > > > > When trying to run the example FileSystemCollectionReader.xml, which is find in [UIMA-HOME]/examples/descriptors/collection_reader/FileSystemCollectionReader.xml > > I get the below message. I also get the same message with org.apache.uima.examples.cpe.FileSystemCollectionReader and everything else in org.apache.uima.examples.cpe > > Thanks, > > Andrew Borthwick > > __ > > org.apache.uima.resource.ResourceInitializationException: The class org.apache.uima.examples.xmi.XmiWriterCasConsumer could not be found. (Descriptor: /home/andrew/uima/apache-uima/examples/descriptors/cas_consumer/XmiWriterCasConsumer.xml) > > at org.apache.uima.collection.impl.CollectionProcessingEngine_impl.initialize(CollectionProcessingEngine_impl.java:83) > > at org.apache.uima.impl.UIMAFramework_impl._produceCollectionProcessingEngine(UIMAFramework_impl.java:395) > > at org.apache.uima.UIMAFramework.produceCollectionProcessingEngine(UIMAFramework.java:807) > > at org.apache.uima.tools.cpm.CpmPanel.startProcessing(CpmPanel.java:538) > > at org.apache.uima.tools.cpm.CpmPanel.access$000(CpmPanel.java:96) > > at org.apache.uima.tools.cpm.CpmPanel$1.construct(CpmPanel.java:678) > > at org.apache.uima.tools.util.gui.SwingWorker$2.run(SwingWorker.java:130) > > at java.lang.Thread.run(Thread.java:595) > > Caused by: org.apache.uima.resource.ResourceConfigurationException: The class org.apache.uima.examples.xmi.XmiWriterCasConsumer could not be found. (Descriptor: /home/andrew/uima/apache-uima/examples/descriptors/cas_consumer/XmiWriterCasConsumer.xml) > > at org.apache.uima.collection.impl.cpm.container.CPEFactory.isDefinitionInstanceOf(CPEFactory.java:661) > > at org.apache.uima.collection.impl.cpm.container.CPEFactory.produceIntegratedCasProcessor(CPEFactory.java:1076) > > at org.apache.uima.collection.impl.cpm.container.CPEFactory.getCasProcessors(CPEFactory.java:550) > > at org.apache.uima.collection.impl.cpm.BaseCPMImpl.init(BaseCPMImpl.java:253) > > at org.apache.uima.collection.impl.cpm.BaseCPMImpl.(BaseCPMImpl.java:127) > > at org.apache.uima.collection.impl.CollectionProcessingEngine_impl.initialize(CollectionProcessingEngine_impl.java:75) > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
[jira] Assigned: (UIMA-443) fix flow ResultSpec handling
[ https://issues.apache.org/jira/browse/UIMA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-443: --- Assignee: Adam Lally > fix flow ResultSpec handling > > > Key: UIMA-443 > URL: https://issues.apache.org/jira/browse/UIMA-443 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Michael Baessler >Assignee: Adam Lally > Fix For: 2.2 > > > Currently it is possible to set a result spec for a flow node > AnalysisSequenceCapabilityNode.setResultSpec(). But it seems that this > feature is never supported in UIMA 2.x. We should either remove/deprecate > this APIs if this is really true that it is never supported. > But I think that this was a very important feature for search engine > integrations, so I would vote for adding this functionality again to the > FlowController stuff. Let's start the discussion on how this can be done and > what we will do for UIMA 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (UIMA-443) fix flow ResultSpec handling
[ https://issues.apache.org/jira/browse/UIMA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on UIMA-443 started by Adam Lally. > fix flow ResultSpec handling > > > Key: UIMA-443 > URL: https://issues.apache.org/jira/browse/UIMA-443 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Michael Baessler >Assignee: Adam Lally > Fix For: 2.2 > > > Currently it is possible to set a result spec for a flow node > AnalysisSequenceCapabilityNode.setResultSpec(). But it seems that this > feature is never supported in UIMA 2.x. We should either remove/deprecate > this APIs if this is really true that it is never supported. > But I think that this was a very important feature for search engine > integrations, so I would vote for adding this functionality again to the > FlowController stuff. Let's start the discussion on how this can be done and > what we will do for UIMA 2.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-463) Can't find org.apache.uima.examples.xmi
[ https://issues.apache.org/jira/browse/UIMA-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506895 ] Adam Lally commented on UIMA-463: - Hmm, it shouldn't be necessary to add uimaj-examples.jar to the classpath for the uimaj-examples project, because the source code for the examples should be in the uimaj-examples project itself. So Eclipse should compile it and make those classes available in your project classpath. Can you check the Eclipse "Problems" view and see if it lists any compilation errors? > Can't find org.apache.uima.examples.xmi > --- > > Key: UIMA-463 > URL: https://issues.apache.org/jira/browse/UIMA-463 > Project: UIMA > Issue Type: Bug > Components: Examples > Environment: Eclipse 3.2.2, ubuntu linux 7.04, JRE: > java-1.5.0-sun-1.5.0.11 >Reporter: Andrew Borthwick > > When trying to run the example FileSystemCollectionReader.xml, which is find > in > [UIMA-HOME]/examples/descriptors/collection_reader/FileSystemCollectionReader.xml > I get the below message. I also get the same message with > org.apache.uima.examples.cpe.FileSystemCollectionReader and everything else > in org.apache.uima.examples.cpe > Thanks, > Andrew Borthwick > __ > org.apache.uima.resource.ResourceInitializationException: The class > org.apache.uima.examples.xmi.XmiWriterCasConsumer could not be found. > (Descriptor: > /home/andrew/uima/apache-uima/examples/descriptors/cas_consumer/XmiWriterCasConsumer.xml) > at > org.apache.uima.collection.impl.CollectionProcessingEngine_impl.initialize(CollectionProcessingEngine_impl.java:83) > at > org.apache.uima.impl.UIMAFramework_impl._produceCollectionProcessingEngine(UIMAFramework_impl.java:395) > at > org.apache.uima.UIMAFramework.produceCollectionProcessingEngine(UIMAFramework.java:807) > at org.apache.uima.tools.cpm.CpmPanel.startProcessing(CpmPanel.java:538) > at org.apache.uima.tools.cpm.CpmPanel.access$000(CpmPanel.java:96) > at org.apache.uima.tools.cpm.CpmPanel$1.construct(CpmPanel.java:678) > at > org.apache.uima.tools.util.gui.SwingWorker$2.run(SwingWorker.java:130) > at java.lang.Thread.run(Thread.java:595) > Caused by: org.apache.uima.resource.ResourceConfigurationException: The class > org.apache.uima.examples.xmi.XmiWriterCasConsumer could not be found. > (Descriptor: > /home/andrew/uima/apache-uima/examples/descriptors/cas_consumer/XmiWriterCasConsumer.xml) > at > org.apache.uima.collection.impl.cpm.container.CPEFactory.isDefinitionInstanceOf(CPEFactory.java:661) > at > org.apache.uima.collection.impl.cpm.container.CPEFactory.produceIntegratedCasProcessor(CPEFactory.java:1076) > at > org.apache.uima.collection.impl.cpm.container.CPEFactory.getCasProcessors(CPEFactory.java:550) > at > org.apache.uima.collection.impl.cpm.BaseCPMImpl.init(BaseCPMImpl.java:253) > at > org.apache.uima.collection.impl.cpm.BaseCPMImpl.(BaseCPMImpl.java:127) > at > org.apache.uima.collection.impl.CollectionProcessingEngine_impl.initialize(CollectionProcessingEngine_impl.java:75) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-459) References html file has 0 bytes after clean build
[ https://issues.apache.org/jira/browse/UIMA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506245 ] Adam Lally commented on UIMA-459: - I seem to recall there was some problem building the docbooks with IBM Java 1.4 (or maybe it was some other Java, I'm not sure). Could that be causing this? > References html file has 0 bytes after clean build > -- > > Key: UIMA-459 > URL: https://issues.apache.org/jira/browse/UIMA-459 > Project: UIMA > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2 >Reporter: Thilo Goetz >Assignee: Marshall Schor > Fix For: 2.2 > > > When built separately, the references html file is generated correctly. When > the whole docbook build is run, for example in a clean extract, the > references.html is empty (while the pdf is generated correctly). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default Result Specifications too complicated?
On 6/18/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: Adam Lally wrote: > It seems like there is a tradeoff here between supporting users > migrating from 1.4 to 2.2, versus supporting users migrating from 2.0 > or 2.1 to 2.2, is there not? But for 2.1 users it's easy, they just need to rename the flow. 1.4 users really need to think if the new flow still does what they need. I guess it's just my thinking that it's better to break something between 1.x and 2.x than it is between 2.x and 2.y. And given that the "breaking" has already been done and has been around for a while, one break is better than two. But again... at this point if I hear Marshall and Eddie say they want to rename CLF to LF, then fine, let's do that. OTOH, we could just repair the CLF to work like 1.4, and nobody would have any problems. I think it would be good for everyone to go back and read the original note in this thread, that started all this discussion. (Here's a link if you need that: http://www.mail-archive.com/uima-dev@incubator.apache.org/msg02759.html). We need to decide on the future of the ResultSpecification. Is it just for optimization or not? -Adam
Re: Default Result Specifications too complicated?
On 6/18/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: If we need to go this route, we'd rather implement a custom flow. That seems the lesser evil. Can you do what you need using a flow controller? The core of this problem is the that the FlowController interface does not allow the custom flow controller to set the Result Specification for the annotators that are called. The use case Michael gave was that you need to call an annotator that is capable of producing both Tokens and Sentences, but have it produce only Sentences. To me this is the absolute minimum of what we need to do to address this issue. For users who are migrating from 1.4 to 2.1, the CLF is broken, warnings in the migration script notwithstanding. Only removing this functionality, at least under this name, will force users to think about what they are going to do with their flows. It seems like there is a tradeoff here between supporting users migrating from 1.4 to 2.2, versus supporting users migrating from 2.0 or 2.1 to 2.2, is there not? -Adam
[jira] Closed: (UIMA-449) XMI serialization does not work with Sun Java 1.5.0_12
[ https://issues.apache.org/jira/browse/UIMA-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-449. --- Resolution: Fixed > XMI serialization does not work with Sun Java 1.5.0_12 > -- > > Key: UIMA-449 > URL: https://issues.apache.org/jira/browse/UIMA-449 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 > Environment: Sun Java 1.5.0_12 >Reporter: Adam Lally >Assignee: Adam Lally >Priority: Critical > Fix For: 2.2 > > > For some reason when running Sun Java 1.5.0_12, serialized XMI does not > contain any XML namespace declarations (xmlns attributes). This did not > happen with earlier builds of Sun Java 1.5.0. > This bug causes UIMA tooling such as the DocumentAnalyzer to break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default Result Specifications too complicated?
To update this thread: We've determined that the particular use case we know about that was relying on this feature of the capabilityLanguageFlow could be addressed by changing the annotator code if necessary, to check for existence of Tokens in the CAS before creating additional Tokens. Of course it isn't ideal that the annotator code would have to change, but at least it is a possibility since other options aren't ideal either. The questions we still need to reach agreement on are: (1) Should we change Apache UIMA to allow the FlowController to set the ResultSpecification of annotators it calls, so that we can have a capabilityLanguageFlow that behaves the exactly the same as it did in 1.x? (2) If the answer to #1 is no, should we remove the capabilityLanguageFlow from Apache UIMA 2.2, perhaps renaming it to languageFlow or something like that? We might (?) have reached some sort of reluctant consensus on (1) that we aren't going to change this, with Michael and perhaps Thilo agreeing to disagree, but I am not sure. We seem far apart still on (2). Ultimately I don't think I would stand in the way of renaming capabilityLanguageFlow if that is the consensus of the other committers. -Adam On 6/12/07, Adam Lally <[EMAIL PROTECTED]> wrote: On 6/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: > no, this is not an option. So you vote against the option... that is fine, it doesn't mean it isn't an option *to consider*. > We have users who use the capabilityLanguageFlow > in 1.4 in ways that will break in 2.x. I don't want them to migrate to Apache > UIMA, happily use that flow and then have things break in subtle ways. We > either fix it so it's backwards compatible, or we rename it so people don't > think it's the same. > We said in the 2.0 "what's new" - there have been changes in the ResultSpecification, we don't guarantee applications that use them will be backwards compatible. We can add to that the same thing for languageCapabilityFlow. Sometimes, things change between 1.x and 2.x. Removing/renaming capabilityLanguageFlow completely just unilaterally breaks everybody just to avoid confusing a handful (or less) of users that might have been effected. > > > > While adding a SimpleStepWithResultSpec is a possibility for backwards > > compatibility, I'm really not that happy with that idea going forward, > > since it encourages people to build applications that rely on Result > > Specifications. I think Result Specifications should only be a > > performance optimization. Since only a handful of annotators in the > > world pay attention to their Result Spec at all, I think it's not a > > very good idea for applications to rely on them. In your example, if > > the second annotator produces tokens will this be just a performance > > problem or will the application actually break? > > The application will break. > I recommend we make it explicit that applications cannot expect annotators to observe the Result Specification. If an application is going to do this then it might as well rely on the annotator to check the CAS for existing Tokens before creating new ones, as I suggested. This one obscure use case can be handled in an application-specific way, rather than adding complexity to the framework. Result Specs are complicated enough (the original point of this issue) if they are deterministically determined based on the descriptors. If FlowControllers can set them arbitrarily the poor users will have no hope to understand why they aren't getting the results they expect. -Adam
[jira] Created: (UIMA-456) Make our Eclipse plugin projects into PDE projects
Make our Eclipse plugin projects into PDE projects -- Key: UIMA-456 URL: https://issues.apache.org/jira/browse/UIMA-456 Project: UIMA Issue Type: Improvement Components: Build, Packaging and Test Reporter: Adam Lally Priority: Minor Joern submitted a patch that changed the uimaj-ep-runtime project to be an Eclipse PDE project. This was done by changing the Maven POM and assembly descriptors appropriately. It would be nice if all of our plugin projects worked in this way. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (UIMA-449) XMI serialization does not work with Sun Java 1.5.0_12
XMI serialization does not work with Sun Java 1.5.0_12 -- Key: UIMA-449 URL: https://issues.apache.org/jira/browse/UIMA-449 Project: UIMA Issue Type: Bug Components: Core Java Framework Affects Versions: 2.1 Environment: Sun Java 1.5.0_12 Reporter: Adam Lally Assignee: Adam Lally Priority: Critical Fix For: 2.2 For some reason when running Sun Java 1.5.0_12, serialized XMI does not contain any XML namespace declarations (xmlns attributes). This did not happen with earlier builds of Sun Java 1.5.0. This bug causes UIMA tooling such as the DocumentAnalyzer to break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Assigned: (UIMA-402) Adding Remote SOAP AE to Aggregate in CDE causes validation error
On 6/14/07, Marshall Schor <[EMAIL PROTECTED]> wrote: Adam Lally (JIRA) wrote: > [ https://issues.apache.org/jira/browse/UIMA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Adam Lally reassigned UIMA-402: > --- > > Assignee: Marshall Schor (was: Adam Lally) > > Marshall, I added the uima-core support for this. Assigning to you to update the CDE. > > I added a new method CasCreationUtils.mergeDelegateAnalysisEngineMetaData which merges type systems, priorities, and indexes. It also takes a parameter that will be populated with information about > remote delegates that could not be contacted, rather than throwing an exception in this case. > Adam, I see the CDE makes use of individual merge calls for the type system, the type priorities, and the index repositories. I examined the code to see if the CDE could switch to just one call that merged everything - it's fairly complex code, which I think would be risky to change. So I'd like instead have versions of the individual part merge code. I can do the changes unless there's something un-obvious about this that I would miss? Or, if you want to do this, let me know... -Marshall I am trying to fight the explosion of the number of methods in CasCreationUtils that all do similar things. It's already a jungle in there. Also I'd rather encourage users to merge it all at once since then you don't have to contact remotes more than once. Maybe you can put the code that you need into the CDE rather than into uimaj-core? The easiest thing to do would be to just call mergeDelegateAnalysisEngineMetaData and then extract the part you need. If you are concerned that this wouldn't perform well enough (say the type system merge is complicated and you don't want to pay the price each time you merge the fs indexes), then you could do a better implementation where you copy the code from CasCreationUtils.mergeDelegateAnalysisEngineMetaData and split it into three different methods in the CDE. -Adam
Re: Default Result Specifications too complicated?
On 6/12/07, Thilo Goetz <[EMAIL PROTECTED]> wrote: no, this is not an option. So you vote against the option... that is fine, it doesn't mean it isn't an option *to consider*. We have users who use the capabilityLanguageFlow in 1.4 in ways that will break in 2.x. I don't want them to migrate to Apache UIMA, happily use that flow and then have things break in subtle ways. We either fix it so it's backwards compatible, or we rename it so people don't think it's the same. We said in the 2.0 "what's new" - there have been changes in the ResultSpecification, we don't guarantee applications that use them will be backwards compatible. We can add to that the same thing for languageCapabilityFlow. Sometimes, things change between 1.x and 2.x. Removing/renaming capabilityLanguageFlow completely just unilaterally breaks everybody just to avoid confusing a handful (or less) of users that might have been effected. > > While adding a SimpleStepWithResultSpec is a possibility for backwards > compatibility, I'm really not that happy with that idea going forward, > since it encourages people to build applications that rely on Result > Specifications. I think Result Specifications should only be a > performance optimization. Since only a handful of annotators in the > world pay attention to their Result Spec at all, I think it's not a > very good idea for applications to rely on them. In your example, if > the second annotator produces tokens will this be just a performance > problem or will the application actually break? The application will break. I recommend we make it explicit that applications cannot expect annotators to observe the Result Specification. If an application is going to do this then it might as well rely on the annotator to check the CAS for existing Tokens before creating new ones, as I suggested. This one obscure use case can be handled in an application-specific way, rather than adding complexity to the framework. Result Specs are complicated enough (the original point of this issue) if they are deterministically determined based on the descriptors. If FlowControllers can set them arbitrarily the poor users will have no hope to understand why they aren't getting the results they expect. -Adam
[jira] Assigned: (UIMA-402) Adding Remote SOAP AE to Aggregate in CDE causes validation error
[ https://issues.apache.org/jira/browse/UIMA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-402: --- Assignee: Marshall Schor (was: Adam Lally) Marshall, I added the uima-core support for this. Assigning to you to update the CDE. I added a new method CasCreationUtils.mergeDelegateAnalysisEngineMetaData which merges type systems, priorities, and indexes. It also takes a parameter that will be populated with information about remote delegates that could not be contacted, rather than throwing an exception in this case. > Adding Remote SOAP AE to Aggregate in CDE causes validation error > - > > Key: UIMA-402 > URL: https://issues.apache.org/jira/browse/UIMA-402 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Affects Versions: 2.1 > Reporter: Adam Lally >Assignee: Marshall Schor > Fix For: 2.2 > > > User bug report: > I came cross a problem with > org.apache.uima.desceditor.2.1.0.incubating-hotfix-1 when porting my UIMA > programs from the ibm 2.0.0 to apache uima. > To make an aggregate AE, I added a remote Soap AE service using the "Add > Remote" function of the CDE, then I got error message: > "The Resource Factory foes not know how to create a resource of class > org.apache.uima.resource.Resource from the given ResourceSpecifier. > (Descriptor: file_path...)" > The descriptor passed is a very simple Soap service descriptor. And when I > tried it with UIMA Document Analyzer tool, it worked well. Just the CDE keeps > throwing this error message. It didn't happen either with the old CDE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work started: (UIMA-402) Adding Remote SOAP AE to Aggregate in CDE causes validation error
[ https://issues.apache.org/jira/browse/UIMA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on UIMA-402 started by Adam Lally. > Adding Remote SOAP AE to Aggregate in CDE causes validation error > - > > Key: UIMA-402 > URL: https://issues.apache.org/jira/browse/UIMA-402 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Affects Versions: 2.1 > Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > User bug report: > I came cross a problem with > org.apache.uima.desceditor.2.1.0.incubating-hotfix-1 when porting my UIMA > programs from the ibm 2.0.0 to apache uima. > To make an aggregate AE, I added a remote Soap AE service using the "Add > Remote" function of the CDE, then I got error message: > "The Resource Factory foes not know how to create a resource of class > org.apache.uima.resource.Resource from the given ResourceSpecifier. > (Descriptor: file_path...)" > The descriptor passed is a very simple Soap service descriptor. And when I > tried it with UIMA Document Analyzer tool, it worked well. Just the CDE keeps > throwing this error message. It didn't happen either with the old CDE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-74) make Eclipse plugins into features that can be installed by Eclipse update mechanism
[ https://issues.apache.org/jira/browse/UIMA-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally updated UIMA-74: --- Priority: Major (was: Minor) Upgraded priority to major since users seems to have a lot of troubles installing our plugins. In particular if there is anyway to automatically install the right EMF version that would be great. Or failing that, some better way for the user to be notified if they have not installed the right EMF version. > make Eclipse plugins into features that can be installed by Eclipse update > mechanism > > > Key: UIMA-74 > URL: https://issues.apache.org/jira/browse/UIMA-74 > Project: UIMA > Issue Type: Improvement > Components: Eclipse plugins >Reporter: Marshall Schor > > Figure out an approach that's consistent with other Apache projects. Figure > out Feature packaging (one or multiple features?). Change build to support > this. Figure out test approach. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default Result Specifications too complicated?
On 6/11/07, Michael Baessler <[EMAIL PROTECTED]> wrote: OK, for the next release I think we have to possibilities... 1) we implement the SimpleStepWithResultSpec function to fix the capabilityLanguageFlow as it was in UIMA 1.4. This allows UIMA 1.4 users that use the capabilityLanguageFlow to migrate to Apache UIMA 2.2. 2) we do not implement the SimpleStepWithResultSpec and remove the capabilityLanguageFlow completely since it has not the same functionality as in UIMA 1.4. So users that want to migrate see that they cannot use this functionality with Apache UIMA 2.2 and have to implement their own flow based on their type system. But this would break user code that is based on the capabilityLanguageFlow. Using the capabilityLanguageFlow code with a different flow name will also be possible, but I don't think that this helps us in our decision. I think leaving things the way they are is also an option to consider. capabilityLanguageFlow still works in many cases (as evidenced by the fact that our test cases still pass). While adding a SimpleStepWithResultSpec is a possibility for backwards compatibility, I'm really not that happy with that idea going forward, since it encourages people to build applications that rely on Result Specifications. I think Result Specifications should only be a performance optimization. Since only a handful of annotators in the world pay attention to their Result Spec at all, I think it's not a very good idea for applications to rely on them. In your example, if the second annotator produces tokens will this be just a performance problem or will the application actually break? An alternative way of doing things would be for the second annotator to check for existence of tokens before creating more tokens. This requires special support in the annotator, certainly, but so does requiring the annotator to pay attention to its result spec, so I don't think we are any worse off. -Adam
[jira] Assigned: (UIMA-402) Adding Remote SOAP AE to Aggregate in CDE causes validation error
[ https://issues.apache.org/jira/browse/UIMA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-402: --- Assignee: Adam Lally > Adding Remote SOAP AE to Aggregate in CDE causes validation error > - > > Key: UIMA-402 > URL: https://issues.apache.org/jira/browse/UIMA-402 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Affects Versions: 2.1 > Reporter: Adam Lally >Assignee: Adam Lally > Fix For: 2.2 > > > User bug report: > I came cross a problem with > org.apache.uima.desceditor.2.1.0.incubating-hotfix-1 when porting my UIMA > programs from the ibm 2.0.0 to apache uima. > To make an aggregate AE, I added a remote Soap AE service using the "Add > Remote" function of the CDE, then I got error message: > "The Resource Factory foes not know how to create a resource of class > org.apache.uima.resource.Resource from the given ResourceSpecifier. > (Descriptor: file_path...)" > The descriptor passed is a very simple Soap service descriptor. And when I > tried it with UIMA Document Analyzer tool, it worked well. Just the CDE keeps > throwing this error message. It didn't happen either with the old CDE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (UIMA-402) Adding Remote SOAP AE to Aggregate in CDE causes validation error
Any opinions on this issue? Should we try to get in for 2.2? -Adam On 6/5/07, Adam Lally (JIRA) wrote: [ https://issues.apache.org/jira/browse/UIMA-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501723 ] Adam Lally commented on UIMA-402: - Marshall wrote (on uima-dev): >Basic thought: if the user of the CDE sets it up so the soap axis jars >are available (is there a way to do that?), then things would work nicely. The jars would have to be listed in the uima runtime plugin manifest. So unless we wanted to ship the plugin with extra entries in its manifest, this would require the user editing the manifest file which is pretty ugly. Or is there another way? >The CDE has several places where it attempts to get remote metadata. It >is designed in such a way as to be able to proceed if the remote isn't >available (e.g., it isn't started, or in this case, there are jar files >missing). >Maybe the best thing would be to have >mergeDelegateAnalysisEngineTypeSystems try to contact remote services, >succeed where it can, and when it cannot, to skip just those that can't >be contacted, for whatever reason (service isn't running, or JARs needed >are missing). Of course, you would not want this behavior for actually >running - so another argument might be needed to control this. And, the >CDE would like to know if any remotes could not be contacted - I'm >thinking it should pop up a warning message in this case, saying that >the fully-merged type system may be missing some types. OK, makes sense... so shall I add define yet another version of mergeDelegateAnalysisEngienTypeSystems (there are already 3)? It could be: public static TypeSystemDescription mergeDelegateAnalysisEngineTypeSystems( AnalysisEngineDescription aAggregateDescription, ResourceManager aResourceManager, Map aOutputMergedTypes, Collection aOutputFailedRemotes); The method would add an entry to aOutputFailedRemotes for each remote delegate that could not be contacted. Agree? > Adding Remote SOAP AE to Aggregate in CDE causes validation error > - > > Key: UIMA-402 > URL: https://issues.apache.org/jira/browse/UIMA-402 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Affects Versions: 2.1 >Reporter: Adam Lally > Fix For: 2.2 > > > User bug report: > I came cross a problem with org.apache.uima.desceditor.2.1.0.incubating-hotfix-1 when porting my UIMA programs from the ibm 2.0.0 to apache uima. > To make an aggregate AE, I added a remote Soap AE service using the "Add Remote" function of the CDE, then I got error message: > "The Resource Factory foes not know how to create a resource of class org.apache.uima.resource.Resource from the given ResourceSpecifier. (Descriptor: file_path...)" > The descriptor passed is a very simple Soap service descriptor. And when I tried it with UIMA Document Analyzer tool, it worked well. Just the CDE keeps throwing this error message. It didn't happen either with the old CDE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: typeSystemInit() and AnnotatorProcessException
On 6/11/07, Michael Baessler <[EMAIL PROTECTED]> wrote: For errors in the typeSystemInit() method of an annotator, annotator writers can throw an AnnotatorConfigurationException or an AnnotatorInitializationException. Since the typeSystemInit() method is called during the annotator process() method if the type system of the CAS has changed, the process() method interface only allows to throw AnalysisEngineProcessExceptions. So in case of AnnotatorConfigurationExceptions or AnnotatorInitializationExceptions thrown by the typeSystemInit() method the UIMA framework wraps these into an AnalysisEngineProcessException. For applications it is now hard to detect the cause of the error. They ever have to check for underlying exceptions to decide if the error was a document processing error or a configuration/initialization error. I think this is not very intuitive and possibly unexpected by the users that they get an AnalysisEngineProcessException that was caused by an configuration/initialization error. Is this something that we can fix? For example to allow the UIMA process() method additionally to throw an AnntatorInitializationException? If not, I think we should at least document that behavior. What do others think? The exception situation isn't ideal. But adding new exception types to methods will break user code, and I don't think it is worth it. An alternative that wouldn't break compatibility would be to subtype AnalysisEngineProcessException - or add a field to it then indicates the "kind" of exception. We've also had user requests for a standard kind of "bad document" error. See UIMA-340. -Adam
[jira] Commented: (UIMA-360) Add CAS change notifications
[ https://issues.apache.org/jira/browse/UIMA-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503434 ] Adam Lally commented on UIMA-360: - Change notification may also help if we want to implement "delta" responses from a service -- that is, the service replying only with the changes that it performed, rather than the entire CAS. This could be a significant performance savings for distributed deployments, where we are currently wasting time serializing and echoing the entire CAS contents. > Add CAS change notifications > > > Key: UIMA-360 > URL: https://issues.apache.org/jira/browse/UIMA-360 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Jörn Kottmann > Attachments: cas editor doc.txt, images.zip > > > Add a facility to listen to changes which are made to the CAS. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-437) Annotators are not prevented from calling CAS.release()
[ https://issues.apache.org/jira/browse/UIMA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-437. --- Resolution: Fixed Fixed. Also discovered and fixed a bug that was causing CASes released by a CAS multiplier to still be counted against its total number of checked out CASes, used for error checking purposes. > Annotators are not prevented from calling CAS.release() > > > Key: UIMA-437 > URL: https://issues.apache.org/jira/browse/UIMA-437 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework > Reporter: Adam Lally > Assignee: Adam Lally > Fix For: 2.2 > > > Annotators are prohibited from calling CAS.reset() but not CAS.release(). > Since release() in turn calls reset(), previously this was effectively > prohibited as well. However, Marshall undid that in his recent work - making > release() "unlock" the CAS prohibited functions. > This was done to allow CAS Mutipliers to release the CAS - which we currently > say is a best practice when an error occurs in a CAS Multiplier. > So I think CAS Multipliers need to be allowed to call release() on CASes that > they obtain from the CAS pool. But analysis components (either annotators or > CAS multipliers) should not be allowed to release() CASes passed to their > process() methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-442) FileUtilsTest fail on Linux
[
https://issues.apache.org/jira/browse/UIMA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Lally resolved UIMA-442.
-
Resolution: Fixed
Should be fixed now.
> FileUtilsTest fail on Linux
> ---
>
> Key: UIMA-442
> URL: https://issues.apache.org/jira/browse/UIMA-442
> Project: UIMA
> Issue Type: Bug
> Components: Build, Packaging and Test
>Affects Versions: 2.1
> Environment: Ubuntu Linux 7.04- SUN Java 6 (1.6.0-b105), Eclipse
> 3.3RC3, Maven 2.0.6
>Reporter: Roberto Franchini
>Assignee: Adam Lally
> Fix For: 2.2
>
>
> The FileUtilsTest fails on linux while using windows path:
> base = new File("c:/foo/bar/baz/dir/");
> target = new File("c:/foo/d1/d2/d3/blah.xml");
> assertEquals("../../../d1/d2/d3/blah.xml",
> FileUtils.findRelativePath(target, base));
> Eclipse JUnit trace:
> junit.framework.ComparisonFailure: expected:<./../d1/d2/d3/...> but
> was:<...c:\foo\d1\d2\d3\...>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at
> org.apache.uima.util.FileUtilsTest.testFindRelativePath(FileUtilsTest.java:41)
> [snip]
> Maven fails too:
> ...
> Running org.apache.uima.util.FileUtilsTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec <<<
> FAILURE!
> ...
> Results :
> Failed tests:
> testFindRelativePath(org.apache.uima.util.FileUtilsTest)
> Tests run: 363, Failures: 1, Errors: 0, Skipped: 0
> ...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (UIMA-437) Annotators are not prevented from calling CAS.release()
[ https://issues.apache.org/jira/browse/UIMA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally reassigned UIMA-437: --- Assignee: Adam Lally (was: Marshall Schor) > Annotators are not prevented from calling CAS.release() > > > Key: UIMA-437 > URL: https://issues.apache.org/jira/browse/UIMA-437 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework > Reporter: Adam Lally > Assignee: Adam Lally > Fix For: 2.2 > > > Annotators are prohibited from calling CAS.reset() but not CAS.release(). > Since release() in turn calls reset(), previously this was effectively > prohibited as well. However, Marshall undid that in his recent work - making > release() "unlock" the CAS prohibited functions. > This was done to allow CAS Mutipliers to release the CAS - which we currently > say is a best practice when an error occurs in a CAS Multiplier. > So I think CAS Multipliers need to be allowed to call release() on CASes that > they obtain from the CAS pool. But analysis components (either annotators or > CAS multipliers) should not be allowed to release() CASes passed to their > process() methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-387) XMI Serializer can write invalid control characters
[ https://issues.apache.org/jira/browse/UIMA-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503398 ] Adam Lally commented on UIMA-387: - I think the fix in this issue is a step in the right direction. A next step would be to make it easier for people to use XML 1.1, which has far fewer invalid characters. If people use XML 1.1, then I think there are only two types of invalid data: character #0, and invalid surrogate pairs. I think it might be right to explicitly state that such data is not supported in Strings in the UIMA CAS. Whether we actually check for it, though, I'm not so sure about, since it could hurt performance for time-critical applications that never intend to do XML serialization anyway. > XMI Serializer can write invalid control characters > --- > > Key: UIMA-387 > URL: https://issues.apache.org/jira/browse/UIMA-387 > Project: UIMA > Issue Type: Bug > Components: Core Java Framework >Affects Versions: 2.1 >Reporter: Adam Lally >Assignee: Thilo Goetz > Fix For: 2.2 > > > On 5/1/07, Leo Ferres <[EMAIL PROTECTED]> wrote: > > Hello, > > > > While trying to open an xmi file after processing in xml view, an > > error pops up telling me that there is an invalid xml character. > > the error comes from the sax parser. Below is the stack trace. Thanks > > very much for your help, > > > Most control characters are not allowed in XML 1.0, even if they are > escaped with &#xxx. If your input document contains such characters, > the XMI CAS serializer is writing them to the output XMI document, > making it unreadable. > I checked that if you edit the XMI document and change the first line to: > > The problem goes away, because XML version 1.1 does allow escaped > control characters. > So one possibility for us to fix this in UIMA is to have the XMI CAS > Serializer generate XML version 1.1 tag by default. (I think we > considered that before and decided not to for some reason, maybe we > were worried that other applications might not be able to consume XML > 1.1? I can't remember. :) > Another possibility would be to have the XMI serializer automatically > replace these characters with spaces. The XCAS (not XMI) serializer > does that, but only for the document text, not for feature values. We > could also serialize the XMI using XML version 1.1, which allows > escaped control characters (but still not the 0x00 character). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Axis 2.2 (was Re: 2.2 release)
UIMA hasn't been tested with Axis 2.x. Whether it works depends on how committed Axis is to maintaining backwards compatibility in their APIs. If you find out whether it works, please let us know. -Adam On 5/29/07, Scott Songlin Piao <[EMAIL PROTECTED]> wrote: Will the version 2.2 work with Axis 2.2? If not, any plan to do it? In the website manual of the version 2.1, it is said to support Apache Axis 1.1 or 1.3 only. Scott -Original Message- From: Thilo Goetz [mailto:[EMAIL PROTECTED] Sent: 28 May 2007 16:15 To: uima-dev@incubator.apache.org Subject: Re: 2.2 release Marshall Schor wrote: > Thilo Goetz wrote: >> Hi all, >> >> how are we doing for our next release? I have a couple of minor >> things I want to >> commit, but nothing major. I'd like to propose the following schedule: >> >> 6/1: feature freeze, start testing, make sure documentation is up to date >> 6/8: if no major bugs found, build release candidate and start vote >> >> We have a couple of major items in this release that we need to test >> carefully: >> >> - the new Pear runtime >> - the JCas class loading improvements and CAS reorg >> >> Anything else? > Class loader switching :-) Shouldn't be too hard to do if I don't get > swampped with other work next week. > -Marshall That's actually what I mean by "JCas class loading improvements". --Thilo
[jira] Closed: (UIMA-400) Fix Eclipse plugin
[ https://issues.apache.org/jira/browse/UIMA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Lally closed UIMA-400. --- > Fix Eclipse plugin > -- > > Key: UIMA-400 > URL: https://issues.apache.org/jira/browse/UIMA-400 > Project: UIMA > Issue Type: Bug > Components: Eclipse plugins >Affects Versions: 2.1 >Reporter: Mikhail Sogrin >Assignee: Adam Lally >Priority: Minor > Fix For: 2.2 > > > Manifest for org.apache.uima.runtime plugin in UIMA 2.1 release is not > correct: > - lib/uima-jcas-builtin-types.jar is listed in manifest, but not present in > plugin. > - uima-document-annotation.jar is in distribution, but not in plugin. > - Exported packages are listed twice, with Export-Package and with > Provide-Package. But Provide-Package has been deprecated since Eclipse 3.1. > - Exported package org.apache.uima.tttypesystem does not exist in plugin, was > removed in UIMA-64. > - "Eclipse-BuddyPolicy: registered" is written twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Default Result Specifications too complicated?
On 6/8/07, Michael Baessler <[EMAIL PROTECTED]> wrote:
the old code is still in place that tries to set the result spec for the
next node, but I think it has no effect.
It is in CapabilityLanguageFlowObject.next()
// check if current engine should be called
if (shouldEngineBeCalled == true) {
// set result spec for current analysis engine
node.setResultSpec(currentAnalysisResultSpec);
// return current analysis engine node
return new SimpleStep(node.getCasProcessorKey());
So if the AnalysisSequenceCapabilityNode does not support setting a
ResultSpec than we
should remove this method or at least deprecate it since it is not
support. Also the comment of
this class is wrong!
This isn't a user-facing API, though. This code is now just an
implementation detail of the CapabilityLanguageFlowController. I just
reused the old implementation classes and wrapped them in the new
FlowController interface.
I think that this is a very important feature for search engine
integrations. It's so bad that the test cases did not cover it.
The tests cover only some cases where the annotator isn't called anyway
so we don't see that bad behavior!
How big is the design change to enable the result spec manipulation
again. I know that some of the UIMA 1.4 users want to
migrate to Apache UIMA and they use this feature. So they maybe can't
migrate if this feature is not supported! Maybe there
is a workaround, but this depends on the the annotator capabilities and
is not always possible.
If possible this feature should be in UIMA 2.2.
It's a little tricky since the semantics of Result Spec have changed
to be less of a per-call parameter and instead there is an
AE.setResultSpec call that is stateful. I guess we can make a new
Step type like SimpleStepWithResultSpec (maybe a subtype of
SimpleStep) and then change ASB_impl where it interprets the step so
that it calls setResultSpec on the target AE before invoking that AE's
process method. I'm not sure what all the implications are of doing
that...
Also I don't know when I would have time to do this...
-Adam
Re: UIMA 2.1 with Maven
Just bringing this back to everyone's attention... there were some user requests for us to release our maven artifacts to the apache incubator repository. So perhaps for the 2.2 release we should put these up for vote along with the usual release artifacts. IIRC I addressed all the maven metadata issues raised by Dan Kulp at the last go-around, so they should be ready to go. -Adam On 3/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > We could do this in our next release - it requires Incubator PMC approval. > > We decided to defer this for our first release since we didn't know we > had any users who wanted this. Now we know. :) I'll just add my vote for that. We also use maven2, so a repository would be nice. We've deployed the UIMA jars to our internal repository for now, but having them on a public repository would be nice. Similarly, it would be useful to get a maven2 archetype for annotators that can produce PEAR files. Perhaps all the annotators in the UIMA examples should move to using a PEAR directory structure and PEAR files. And then the UIMA tools should be able to load PEAR files, adding the jars or class files to the classpath at runtime. Greg Holmberg
Re: Default Result Specifications too complicated?
On 6/6/07, Michael Baessler <[EMAIL PROTECTED]> wrote: Here is a short example. Annotator 1 can do Tokens and Lemmas Annotator 2 can do Tokens and Sentences Application is interested in Tokens, Lemmas and Sentences. I guess the default result spec for Annotator 1 is Tokens and Lemmas. The default result spec for Annotator 2 is Tokens and Sentences, right? So if the flow can't manipulate the ResultSpec both annotator will produce Tokens. But this is not the case for the capabilityLanguage flow. Within the capabilityLanguage flow the ResultSpec for the annotators is overridden with a computed ResultSpec from the I guess default ResultSpec. Yes, you are right. That aspect of the capability language flow is no longer supported. I guess we must not have had a unit test for that, since I tried to get all the unit tests to pass when I implemented the custom flow controller. If this functionality is necessary then we'll need to think about how to extend the Flow Controller interface to allow it. Maybe a new Step type that can specify the ResultSpec along with the destination AE? I think it was nice, though, to simply the Result Specs and make them more of a "static" concept rather than something that changes per-CAS. And it's unfortunate if Result Specs cause additional complexity in other parts of UIMA, given that most annotators don't even pay attention to them. > OK. I think what we're leaning towards doing here is just providing > some better checking/tracing for result specs so that it is easier to > debug problems with them. So maybe we have to improve the documentation to explain more detailed how the result spec is working and how it can be manipulated, if I'm right with my assumption above. The documentation is there, somewhere... but it is very difficult for people to even know that they have a Result Spec problem. Most users don't even know what result specs are. So I think documentation alone can't address this issue. Better checking in the framework I think is necessary for this - perhaps some debug mode that people can run in that would tell them when certain types had been excluded from an annotator's result spec, and ideally why they were excluded. -Adam
