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 Tue, 08 Jul 2008 16:21:21 GMT
Adam Lally wrote:
> On Wed, Jul 2, 2008 at 3:06 PM, Marshall Schor <msa@schor.com> wrote:
>   
>> 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)
>>
>>     
>
> Is it possible to have a single release (with a single version number)
> that could have multiple different binary packages (Java framework,
> C++ framework, async scaleout, tools, etc.), where all the parts get
> released and voted on at the same time?  There could be just a single
> source distribution, and then various binaries.  This might make
> things less fragmented and less confusing - for us, the IPMC, and our
> users.
>   
Sure. It has the "pros" that you site.  The "cons" are that it delays 
other parts from being released until the all the parts are ready for 
release.  For instance, the C++ part isn't quite ready for release.  I 
do think that Eclipse is a good model - it has major releases, but the 
other parts do have the ability to do other releases as well.

>   
>> 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.
>>
>>     
>
> Do you mean not up-versioning the Maven artifacts?  We don't have
> version numbers in the jar file names themselves (at least not yet).
> Maybe this fits with my suggestion above - a single release, but with
> the different jars (or other kinds of parts) marked with appropriate
> version numbers.
>   
Right.
>> 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).
>>
>>     
>
> Hmmm... would you also do that for the C++ framework too, and the
> tools, etc.?  Instead, how about an "everything" package that includes
> all the stuff?
>   
I think this issue breaks down into the following considerations:

There are source and binary releases.  The source ones have 2 purposes, 
it seems:
   (a) providing the new, additional sources that make up UIMA-AS
   (b) providing something that users can "build" UIMA-AS from
These are not the same, because the current build process depends on 
sources from the base.  We did a compromise for the first release of 
including some of the sources from the base needed for building.   We 
could and maybe should work on the build-from-source process to have it 
be more modular, and try to make (b) work with (a) sources.

Also, if I understand you right, you're suggesting that we have just an 
"everything" package, instead of these "add-on" packages. If we have 
just an everything package, would we not have a base package?  That 
would mean that people who wanted just uima base would be downloading a 
lot more than they will use. 

We could, of course, have a style where the binaries would be:
   base
   base + annotators
   base + annotators + simple server
   base + uima-as
   base + c++

etc., various "combinations" of the parts.  I think such a packaging 
would get out of hand (too many variants). 

Or, perhaps you're suggesting:
  base
  base + everything else (or a subset of everything else - e.g., 
uima-as, cas editor, annotators, but not the simple server?)

I think our offerings will continue to grow, and may become more diverse 
(e.g., a sample "Type System", or corpora for training, or repository 
functionality might be added).  So I lean toward a strategy that allows 
for some number of "parts" as separately managed things, together with 
an attempt to occasionally put out semi-synchronized "big" releases with 
all or most of the parts, like the Eclipse approach.

-Marshall

Mime
View raw message