Thilo Goetz wrote:
Adam Lally wrote:
On Wed, Jul 2, 2008 at 10:34 AM, Michael Baessler
<[EMAIL PROTECTED]> wrote:
Marshall Schor wrote:
Possible names for this other node might be: "parts". Or we might
want
to have several names that categorized the kinds of things - such as
"annotators", "servers", "embeddings", "corpora", "typeSystems",
"tools", etc.
+1 for having an organization structure based on component type such
as tools, UIMA core,
annotators, etc. But if we change the structure we should also move
the current tools we ship with
the UIMA core bundle to have one place where the user gets tools for
UIMA.
The separation of UIMA core, tools, annotators also has
disadvantage. We never come to the point to
have a rich UIMA framework download where some real analytics are
embedded and work out of the box.
If we want to do that we have to think about a special "analytics
package" where some pre-configured
analysis is included with a special set of descriptors.
I am already thinking we may have enough different releases happening,
if not too many. There is overhead associated with each release,
especially while we're in the incubator and have to bug the IPMC every
time we want to release something. Rather than think about how to
restructure SVN, I prefer we first think about how many different
artifacts we want to be separately releasing. Then I'd agree to
restructure SVN to suit what we decide.
+1, put the horse before the cart.
I agree with the general sentiments above.
We currently have the following "releases" done or being done or planned:
1 - main uima base (released 2.2.2-incubating)
1a - main uima "hot fix" fp1 (out for a vote)
2 - uima-as (it was not ready when the base was, and is just now out for
a vote) <note: this component has a 5D002 export classification>
3 - uima - add-ons (annotators plus the simple server) (released,
2.2.2-incubating)
4 - cas editor (about to go out for a vote)
5 - C++ (soon to go for a vote)
The best thing, of course, would be to exit the incubator :-) so we
could plan this with fewer constraints...
One thing I would like to see at some point going forward is not
up-versioning our Jars when they don't change from release to release.
For instance, when we release uima-base, it includes the jvinci jars -
which haven't been changed recently (I may be wrong here...), but it
would be nice to have that "stability" reflected in the release. I see
that Eclipse often does this in their releases.
Likewise, it would be good to have the uima-as release, which is made to
"depend" on a particular base uima release, just include those jars
(from Maven, for instance) when creating the distributable "bin"
artifact. (We didn't do that for this last release because at the time
we did the build process, uima 2.2.2-incubating wasn't "out" yet).
-Marshall
If we take the current tools out of the current SDK download, we make
it a lot less useful. I think it's a better out of the box experience
if they get one download that includes good tooling. So I'd prefer
seeing mature sandbox tools get integrated into the SDK release rather
than be a separate package.
For annotators, I'm also leaning towards having some good general
purpose annotators included in the SDK. If they start to get more
specialized, then I am not so sure.
Of course this may lead to a bigger download, but my personal feeling
is that this isn't much of a concern. If we start seeing problems or
getting complaints that our release is too big, maybe we go back and
consider splitting it at that point.
-Adam
