[jira] Commented: (UIMA-64) Remove the package org.apache.uima.tttypesystem
[ http://issues.apache.org/jira/browse/UIMA-64?page=comments#action_12452389 ] Thilo Goetz commented on UIMA-64: - The files in this package are pretty useless by themselves, as we don't supply the necessary XML descriptors, nor the actual annotators. These files only contain some constants useful for coding against the TT type system. I don't think moving them to the examples is going to help anybody (they're in the core so they're easily available to all annotators and other code making use of the TT type system). So we'll have to find a different solution, outside of Apache most likely. > Remove the package org.apache.uima.tttypesystem > --- > > Key: UIMA-64 > URL: http://issues.apache.org/jira/browse/UIMA-64 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Adam Lally > Fix For: 2.1 > > > Adam Lally wrote: > > It looks like there's only one reference, from the test cases, and > > that could be replaced. > > > > -Adam > Yes, we need to get rid of it. There are external references, but we'll > have to find a different solution. Please open a JIRA ticket, Michael > or I will take care of it. > --Thilo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (UIMA-64) Remove the package org.apache.uima.tttypesystem
[ http://issues.apache.org/jira/browse/UIMA-64?page=all ] Thilo Goetz reassigned UIMA-64: --- Assignee: Thilo Goetz > Remove the package org.apache.uima.tttypesystem > --- > > Key: UIMA-64 > URL: http://issues.apache.org/jira/browse/UIMA-64 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Adam Lally > Assigned To: Thilo Goetz > Fix For: 2.1 > > > Adam Lally wrote: > > It looks like there's only one reference, from the test cases, and > > that could be replaced. > > > > -Adam > Yes, we need to get rid of it. There are external references, but we'll > have to find a different solution. Please open a JIRA ticket, Michael > or I will take care of it. > --Thilo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (UIMA-64) Remove the package org.apache.uima.tttypesystem
[ http://issues.apache.org/jira/browse/UIMA-64?page=all ] Work on UIMA-64 started by Thilo Goetz. > Remove the package org.apache.uima.tttypesystem > --- > > Key: UIMA-64 > URL: http://issues.apache.org/jira/browse/UIMA-64 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Adam Lally > Assigned To: Thilo Goetz > Fix For: 2.1 > > > Adam Lally wrote: > > It looks like there's only one reference, from the test cases, and > > that could be replaced. > > > > -Adam > Yes, we need to get rid of it. There are external references, but we'll > have to find a different solution. Please open a JIRA ticket, Michael > or I will take care of it. > --Thilo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (UIMA-64) Remove the package org.apache.uima.tttypesystem
[ http://issues.apache.org/jira/browse/UIMA-64?page=all ] Thilo Goetz resolved UIMA-64. - Resolution: Fixed Package has been removed. This should go into the release notes. > Remove the package org.apache.uima.tttypesystem > --- > > Key: UIMA-64 > URL: http://issues.apache.org/jira/browse/UIMA-64 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Adam Lally > Assigned To: Thilo Goetz > Fix For: 2.1 > > > Adam Lally wrote: > > It looks like there's only one reference, from the test cases, and > > that could be replaced. > > > > -Adam > Yes, we need to get rid of it. There are external references, but we'll > have to find a different solution. Please open a JIRA ticket, Michael > or I will take care of it. > --Thilo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (UIMA-64) Remove the package org.apache.uima.tttypesystem
[ http://issues.apache.org/jira/browse/UIMA-64?page=all ] Thilo Goetz closed UIMA-64. --- > Remove the package org.apache.uima.tttypesystem > --- > > Key: UIMA-64 > URL: http://issues.apache.org/jira/browse/UIMA-64 > Project: UIMA > Issue Type: Task > Components: Core Java Framework >Reporter: Adam Lally > Assigned To: Thilo Goetz > Fix For: 2.1 > > > Adam Lally wrote: > > It looks like there's only one reference, from the test cases, and > > that could be replaced. > > > > -Adam > Yes, we need to get rid of it. There are external references, but we'll > have to find a different solution. Please open a JIRA ticket, Michael > or I will take care of it. > --Thilo -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Release manager?
All, if we want to cut a release early next year, we need to get all our ducks in a row. My impression from following incubator-general is that getting the release right is a *lot* of work. It is common practice in Apache projects to have a release manager that takes care of getting the technical details right, and we should start thinking of having one as well (this is not a permanent job by any means, and can change from release to release). I'll volunteer to be the release manager for the first release, but if somebody else wants to do it, please do not hesitate to say so. I would not be unhappy to let somebody else have this job ;-) --Thilo
Availability page on Wiki?
I'll be out of the office with limited email access most of next week. What do people think of having a wiki where people can (voluntarily of course) post that kind of absence? Or is it better to send a note to the list? I personally wouldn't mind posting my absences on the wiki. How does everybody else feel about this? --Thilo
[jira] Commented: (UIMA-50) Add version number to descriptors
[ http://issues.apache.org/jira/browse/UIMA-50?page=comments#action_12452536 ] Tong Fin commented on UIMA-50: -- I believe that having both versions (Framework and DTD/Schema) is useful for the following reason: 1) Tools will use Framework version to identify if the descriptors are appropriate for the Framework being used/targetting. If the tools don't have this info, we need a mapping from DTD/Schema version to Framework. 2) DTD/Schema version will be used when parsing/creating/validating the descriptor > Add version number to descriptors > - > > Key: UIMA-50 > URL: http://issues.apache.org/jira/browse/UIMA-50 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Adam Lally >Priority: Minor > > It has been suggested that our component descriptor XML files should include > a version number, so that it would be possible to give more meaningful error > messages in the case of a version mismatch. I'm not sure whether this should > just be the framework version number, or a different "descriptor model > version number" that might change less frequently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (UIMA-51) Add version number to XCAS (or maybe to CAS built-in typesystem?)
[ http://issues.apache.org/jira/browse/UIMA-51?page=comments#action_12452541 ] Tong Fin commented on UIMA-51: -- Tools do not care how we define the version. But, tools need some way to know if this XCAS/XMI file can be processed by this UIMA version. If we use yet-another-version from built-in CAS type system, we need to "publish" how it is related to the Framework being used/targetting. > Add version number to XCAS (or maybe to CAS built-in typesystem?) > - > > Key: UIMA-51 > URL: http://issues.apache.org/jira/browse/UIMA-51 > Project: UIMA > Issue Type: Improvement > Components: Core Java Framework >Reporter: Adam Lally >Priority: Minor > > From version 1.x to 2.x we broke XCAS compatibility. (v2.x can read v1.x > XCASes but not vice-versa.) We've been thinking we might want to have a > version number on the XCAS so that we can detect an incompatibility and > report a good error message. > It occurs to me that what changed here is not the XCAS syntax, but the > built-in CAS type system. In v2.x the annotation type changed (the "sofa" > feature became a reference instead of an int). Also new primitive types and > new array types were added. > So perhaps the right thing to do is to have a version number on the CAS > built-in type system, and dump that version number in our XCAS (and XMI) > serializations. > I'm not sure if it's right to just use the framework version number (which > might lock us into a versioning scheme such as agreeing not to add new > built-in types without incrementing the major version number), or having a > completely separate version number just for the built-in type system? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Availability page on Wiki?
I don't feel strongly but have a slight preference for this kind of info to be communicated via email. This is for 2 reasons: 1) it needs to be read in a timely way - and email is more timely than wiki reading. (although people might subscribe to wiki changes) 2) it doesn't need to be kept for a long time in a conveniently-accessable place - which wiki's give. -Marshall Thilo Goetz wrote: I'll be out of the office with limited email access most of next week. What do people think of having a wiki where people can (voluntarily of course) post that kind of absence? Or is it better to send a note to the list? I personally wouldn't mind posting my absences on the wiki. How does everybody else feel about this? --Thilo
Re: Release manager?
Thilo Goetz wrote: You're welcome to this job :-) from my point of view. -Marshall All, if we want to cut a release early next year, we need to get all our ducks in a row. My impression from following incubator-general is that getting the release right is a *lot* of work. It is common practice in Apache projects to have a release manager that takes care of getting the technical details right, and we should start thinking of having one as well (this is not a permanent job by any means, and can change from release to release). I'll volunteer to be the release manager for the first release, but if somebody else wants to do it, please do not hesitate to say so. I would not be unhappy to let somebody else have this job ;-) --Thilo
