Re: next release plan - sandbox - which components?
hi there, Lucas should be part of the upcomming 2.3.0 release. rico On Thu, Jul 30, 2009 at 12:56 AM, Tong Fintong.f...@gmail.com wrote: Is the SimpleUimaAsService ready for prime time? I don't recall what it was, but I was looking at it the other day and thought it didn't look quite ready yet. Maybe I'm mistaken. For example, it has the SimpleServer jars checked in as binaries. We surely don't want that, so at least the build ought to be fixed. The rest works, I assume? Is it documented? Anybody using it? I think it has some use. Tong? Thilo - can you please post as many specifics on things that need fixing here or maybe even open Jira issues? I think there are more works to be done for SimpleUimaAsService like JUnit testing and documentation. I prefer to not include SimpleUimaAsService for this next release unless we have users for this project (currently, there is no user (yet) from what I know). -- Tong
Re: next release plan - sandbox - which components?
Hi Rico - thanks for the reminder :-) I'll add it... -Marshall Rico Landefeld wrote: hi there, Lucas should be part of the upcomming 2.3.0 release. rico On Thu, Jul 30, 2009 at 12:56 AM, Tong Fintong.f...@gmail.com wrote: Is the SimpleUimaAsService ready for prime time? I don't recall what it was, but I was looking at it the other day and thought it didn't look quite ready yet. Maybe I'm mistaken. For example, it has the SimpleServer jars checked in as binaries. We surely don't want that, so at least the build ought to be fixed. The rest works, I assume? Is it documented? Anybody using it? I think it has some use. Tong? Thilo - can you please post as many specifics on things that need fixing here or maybe even open Jira issues? I think there are more works to be done for SimpleUimaAsService like JUnit testing and documentation. I prefer to not include SimpleUimaAsService for this next release unless we have users for this project (currently, there is no user (yet) from what I know). -- Tong
Re: next release plan - sandbox - which components?
Thilo Goetz wrote:
Marshall Schor wrote:
Let's get a list of sandbox projects we plan to include in the
2.3.0-incubating release.
The reason for doing this is to better update the version info for the
sandbox. For uimaj we use maven properties and have the version info in
just one place for all the projects. We could do that too, for sandbox
projects which are in the normal release cycle.
Here's the current projects, and my thoughts on including in the release
(quick summary - release all except OpenCalaisAnnotatorGroovy, with some
warinings about projects which may be omitted, if not ready).
Given this, to make the release easier, I propose updating the
SandboxDistr pom to
a) include the new sandbox projects considered for the release, and
b) to define the sandbox release number(s)
and then change the sandbox projects to specify this pom as their parent.
The * in the list below (of all sandbox projects) means it is included
in the sandbox distr currently as a module
BSFAnnotator - yes (bean scripting framework)
CasViewerEclipsePlugin - no (replaced by CasEditor)
ConceptMapper - yes (if ready by release time)(initial release)
ConfigurableFeatureExtractor - yes (if ready by release time)(initial
release)
*DictionaryAnnotator - yes
FsVariables - yes
Lucas - yes (if ready)(initial release)
OpenCalaisAnnotator - yes
OpenCalaisAnnotatorGroovy - no (not updated to work with current Calais
levels)
*PearPackagingAntTask - yes
*PearPackagingMavenPlugin - yes
Are you going to move the PearPackagingMavenPlugin to the core?
There was agreement that we should do so:
http://www.mail-archive.com/uima-dev%40incubator.apache.org/msg09655.html
OK - missed that one. I'll move it to the core.
*RegularExpressionAnnotator -yes
SandboxDistr - yes (shared info used by other projects)
SandboxDocs - yes (shared info used by docbooks)
*SimpleServer - yes
SimpleUimaAsService - yes
Is the SimpleUimaAsService ready for prime time? I don't
recall what it was, but I was looking at it the other day
and thought it didn't look quite ready yet. Maybe I'm
mistaken. For example, it has the SimpleServer jars
checked in as binaries. We surely don't want that, so
at least the build ought to be fixed. The rest works,
I assume? Is it documented? Anybody using it?
I think it has some use. Tong?
Thilo - can you please post as many specifics on things that need fixing
here or maybe even open Jira issues?
SnowballAnnotator - yes
*Tagger - yes (this is the hidden markov model tagger)
TikaAnnotator - yes
uima-as - yes
*WhiteSpaceTokenizer - yes
Currently some of the sandbox projects (e.g. PearPackagingMavenPlug)
have not had their version numbers updated - and I could either update
them to a specific version number (e.g. 2.3.0-incubating-SNAPSHOT) or
use the convention we have for uimaj where we set these to a ${property}
and share the update of that in the SandboxDistr.
Doing this would make the sandbox builds more like the main one, and
consolidate the places where we need to change version numbers.
Definitely +1. Anything that makes the build easier to maintain.
Opinions?
-Marshall
next release plan - sandbox - which components?
Let's get a list of sandbox projects we plan to include in the
2.3.0-incubating release.
The reason for doing this is to better update the version info for the
sandbox. For uimaj we use maven properties and have the version info in
just one place for all the projects. We could do that too, for sandbox
projects which are in the normal release cycle.
Here's the current projects, and my thoughts on including in the release
(quick summary - release all except OpenCalaisAnnotatorGroovy, with some
warinings about projects which may be omitted, if not ready).
Given this, to make the release easier, I propose updating the
SandboxDistr pom to
a) include the new sandbox projects considered for the release, and
b) to define the sandbox release number(s)
and then change the sandbox projects to specify this pom as their parent.
The * in the list below (of all sandbox projects) means it is included
in the sandbox distr currently as a module
BSFAnnotator - yes (bean scripting framework)
CasViewerEclipsePlugin - no (replaced by CasEditor)
ConceptMapper - yes (if ready by release time)(initial release)
ConfigurableFeatureExtractor - yes (if ready by release time)(initial
release)
*DictionaryAnnotator - yes
FsVariables - yes
Lucas - yes (if ready)(initial release)
OpenCalaisAnnotator - yes
OpenCalaisAnnotatorGroovy - no (not updated to work with current Calais
levels)
*PearPackagingAntTask - yes
*PearPackagingMavenPlugin - yes
*RegularExpressionAnnotator -yes
SandboxDistr - yes (shared info used by other projects)
SandboxDocs - yes (shared info used by docbooks)
*SimpleServer - yes
SimpleUimaAsService - yes
SnowballAnnotator - yes
*Tagger - yes (this is the hidden markov model tagger)
TikaAnnotator - yes
uima-as - yes
*WhiteSpaceTokenizer - yes
Currently some of the sandbox projects (e.g. PearPackagingMavenPlug)
have not had their version numbers updated - and I could either update
them to a specific version number (e.g. 2.3.0-incubating-SNAPSHOT) or
use the convention we have for uimaj where we set these to a ${property}
and share the update of that in the SandboxDistr.
Doing this would make the sandbox builds more like the main one, and
consolidate the places where we need to change version numbers.
Opinions?
-Marshall
Re: next release plan - sandbox - which components?
Marshall Schor wrote:
Let's get a list of sandbox projects we plan to include in the
2.3.0-incubating release.
The reason for doing this is to better update the version info for the
sandbox. For uimaj we use maven properties and have the version info in
just one place for all the projects. We could do that too, for sandbox
projects which are in the normal release cycle.
Here's the current projects, and my thoughts on including in the release
(quick summary - release all except OpenCalaisAnnotatorGroovy, with some
warinings about projects which may be omitted, if not ready).
Given this, to make the release easier, I propose updating the
SandboxDistr pom to
a) include the new sandbox projects considered for the release, and
b) to define the sandbox release number(s)
and then change the sandbox projects to specify this pom as their parent.
The * in the list below (of all sandbox projects) means it is included
in the sandbox distr currently as a module
BSFAnnotator - yes (bean scripting framework)
CasViewerEclipsePlugin - no (replaced by CasEditor)
ConceptMapper - yes (if ready by release time)(initial release)
ConfigurableFeatureExtractor - yes (if ready by release time)(initial
release)
*DictionaryAnnotator - yes
FsVariables - yes
Lucas - yes (if ready)(initial release)
OpenCalaisAnnotator - yes
OpenCalaisAnnotatorGroovy - no (not updated to work with current Calais
levels)
*PearPackagingAntTask - yes
*PearPackagingMavenPlugin - yes
Are you going to move the PearPackagingMavenPlugin to the core?
There was agreement that we should do so:
http://www.mail-archive.com/uima-dev%40incubator.apache.org/msg09655.html
*RegularExpressionAnnotator -yes
SandboxDistr - yes (shared info used by other projects)
SandboxDocs - yes (shared info used by docbooks)
*SimpleServer - yes
SimpleUimaAsService - yes
Is the SimpleUimaAsService ready for prime time? I don't
recall what it was, but I was looking at it the other day
and thought it didn't look quite ready yet. Maybe I'm
mistaken. For example, it has the SimpleServer jars
checked in as binaries. We surely don't want that, so
at least the build ought to be fixed. The rest works,
I assume? Is it documented? Anybody using it?
SnowballAnnotator - yes
*Tagger - yes (this is the hidden markov model tagger)
TikaAnnotator - yes
uima-as - yes
*WhiteSpaceTokenizer - yes
Currently some of the sandbox projects (e.g. PearPackagingMavenPlug)
have not had their version numbers updated - and I could either update
them to a specific version number (e.g. 2.3.0-incubating-SNAPSHOT) or
use the convention we have for uimaj where we set these to a ${property}
and share the update of that in the SandboxDistr.
Doing this would make the sandbox builds more like the main one, and
consolidate the places where we need to change version numbers.
Definitely +1. Anything that makes the build easier to maintain.
Opinions?
-Marshall
Re: Release plan
On 1/17/07, Marshall Schor [EMAIL PROTECTED] wrote: What testing beyond the unit tests will we do for this release? Here are some items to consider: 1) test that all the Jira changes that would affect the documentation have had the documentation updated 2) Functional testing, Installation verification testing (I think we need a detailed list - how about a release test plan on the wiki?) Multi-platform testing (Win, *nix) Well for starters, I think it will be useful to for everyone to take some existing UIMA components they have available to them, try to run the migration script and follow the instructions i wrote in the manual, and try to those components in Apache UIMA. -Adam
Re: Release plan
On 12/19/06, Thilo Goetz [EMAIL PROTECTED] wrote: I guess we want about 2 weeks of testing, doc review etc. before that. So this would mean we enter the test phase around the middle of January. So here's a tentative schedule: now - 1/21/07:coding, general enhancements 1/22/07 - 2/4/07: testing bug fixing 2/5/07: cut the release, start the vote 2/15/07: release UIMA 2.1 Let me know what you think. I'll add this to the Wiki once we have agreement on the dev list. I'm assuming we're still on this release plan, though I think it didn't make it to the Wiki. That means done with coding at the end of next week! At this point there's an assignee for each issue that's associated with v2.1 in JIRA. Please make sure you know what's assigned to you, and if it can't be done in time, let the rest of us know. -Adam
Re: Release plan
On 12/19/06, Thilo Goetz [EMAIL PROTECTED] wrote: now - 1/21/07:coding, general enhancements 1/22/07 - 2/4/07: testing bug fixing 2/5/07: cut the release, start the vote 2/15/07: release UIMA 2.1 +1 to this schedule. I'm a little less sure about the plan (on the Wiki) to have a minor release (2.2, 2.3) about every 3 months, without knowing what enhancements we want to get in. I could see releasing something about every 3 months, if in some cases it would just be a maintenance release (e.g., 2.1.1). -Adam
Re: Release plan
Adam Lally wrote: ... I'm a little less sure about the plan (on the Wiki) to have a minor release (2.2, 2.3) about every 3 months, without knowing what enhancements we want to get in. I could see releasing something about every 3 months, if in some cases it would just be a maintenance release (e.g., 2.1.1). -Adam Good point. I'll reword. --Thilo
