uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Considering some re-org of SVN
Date Wed, 02 Jul 2008 19:06:32 GMT
Thilo Goetz wrote:
> Adam Lally wrote:
>> On Wed, Jul 2, 2008 at 10:34 AM, Michael Baessler
>> <mba@michael-baessler.de> 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, 
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).

>> 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

View raw message