Re: UIMA Sandbox releases

[Michael Baessler <mb...@michael-baessler.de>]

Marshall Schor wrote:
> Thilo Goetz wrote:
>   
>> Hi Marshall,
>>
>> as usual, my view is pretty much the exact opposite ;-)
>>
>> First of all, I don't see the sense in creating yet another
>> category.  To my mind, there's nothing wrong with having
>> mature components in the sandbox.  The only thing I would
>> consider is to move some sandbox components that are really
>> important to people into the core.
>>   
>>     
> I think people might feel that the sandbox isn't a place to get
> production-quality things, and I was hoping that some of these
> components were production-quality :-) 
>   
I think Thilo raised a good point here. We still have an "empty 
framework" that does not provide any linguistic functionality out of the 
box. So maybe we should think about moving sandbox components that are 
ready to use and are important for most of the UIMA users to the core. 
We could than also provide some more out of the box analytics by 
combining the components.

For all the other Sandbox components that are ready to use but are not 
relevant for most of the UIMA users we can consider to do a separate 
release for each component. I guess the release cycles are larger for 
those components so that we do not have so much Sandbox component releases.

Opinions?

-- Michael

Re: UIMA Sandbox releases

[Michael Baessler <mb...@michael-baessler.de>]

Sounds good to me... especially the suggestion with the component 
versions that does not change if there is no change!

The other thing I would like to mention again is that from my 
perspective the Sandbox is a place for playing around with new ideas and 
technologies. But if one of the Sandbox components is ready to use in 
"production" I think the component should be moved to the core 
framework. So users get an impression what kind of components are still 
in a development/test phase and what kind of components are "ready to 
use in production". Also this approach helps us to no longer have to 
provide an "empty framework" without any analysis components.

So I'm fine with releasing the CasEditor for now as a single Sandbox 
component.
We could also consider to release some of the annotators in a Sandbox 
annotator bundle.

-- Michael

Marshall Schor wrote:
> Re: releasing the Cas Editor - with or without some pre-packaged 
> annotators.
>
> I suspect that Joern would be willing to be the "release manager" for 
> this :-).  He may even be willing to bundle some of the more "stable" 
> sandbox components with it, but certainly not uima-as (uima-ee), which 
> is not ready.
>
> The pragmatic, least - work approach would be to pick those sandbox 
> projects that would be ready now, and do one "release" packaging that 
> included the Cas Editor.  However, I don't think that's the "clearest" 
> approach for our users.  I think they might like to see bundles 
> arranged by topics - and so might like a bundle of annotators, and 
> might separately like the Cas Editor.
>
> So - my preference for now would be to keep the Cas Editor as a 
> separately packaged thing coming from the project.  If we get 
> additional tools, over time, which we consider "add-ons" and not 
> fundamentally needed as part of the core, then perhaps we can have a 
> tools-bundle.
>
> To do this effectively using the Maven "way" - we might want to have 
> each tool (in one "project") produce one jar (maven way:  each project 
> <=> one jar), at a particular version level.  These would be available 
> in the maven jar repository, and maven tooling could be used to fetch 
> them.   Maven "assemblies" could then be used to package multiples of 
> these into bigger packages of things.  A basic idea here would be that 
> the version of the assembly would be on a different "schedule" than 
> the components.  So someone downloading an assembled "bundle" would 
> get parts, each of which had their own version number.  This is 
> similar to what you get with other big projects that include jars from 
> other sources.  The parts which are stable and not changing would not 
> have their version numbers incremented in the assembled bundle.
>
> -Marshall
>
>
> Michael Baessler wrote:
>> Marshall Schor wrote:
>>> Thilo Goetz wrote:
>>>  
>>>> Hi Marshall,
>>>>
>>>> as usual, my view is pretty much the exact opposite ;-)
>>>>
>>>> First of all, I don't see the sense in creating yet another
>>>> category.  To my mind, there's nothing wrong with having
>>>> mature components in the sandbox.  The only thing I would
>>>> consider is to move some sandbox components that are really
>>>> important to people into the core.
>>>>       
>>> I think people might feel that the sandbox isn't a place to get
>>> production-quality things, and I was hoping that some of these
>>> components were production-quality :-)   
>> I think Thilo raised a good point here. We still have an "empty 
>> framework" that does not provide any linguistic functionality out of 
>> the box. So maybe we should think about moving sandbox components 
>> that are ready to use and are important for most of the UIMA users to 
>> the core. We could than also provide some more out of the box 
>> analytics by combining the components.
>>
>> For all the other Sandbox components that are ready to use but are 
>> not relevant for most of the UIMA users we can consider to do a 
>> separate release for each component. I guess the release cycles are 
>> larger for those components so that we do not have so much Sandbox 
>> component releases.
>>
>> Opinions?
>>
>> -- Michael
>>
>>
>>
>

Re: UIMA Sandbox releases

[Marshall Schor <ms...@schor.com>]

Re: releasing the Cas Editor - with or without some pre-packaged annotators.

I suspect that Joern would be willing to be the "release manager" for 
this :-).  He may even be willing to bundle some of the more "stable" 
sandbox components with it, but certainly not uima-as (uima-ee), which 
is not ready.

The pragmatic, least - work approach would be to pick those sandbox 
projects that would be ready now, and do one "release" packaging that 
included the Cas Editor.  However, I don't think that's the "clearest" 
approach for our users.  I think they might like to see bundles arranged 
by topics - and so might like a bundle of annotators, and might 
separately like the Cas Editor.

So - my preference for now would be to keep the Cas Editor as a 
separately packaged thing coming from the project.  If we get additional 
tools, over time, which we consider "add-ons" and not fundamentally 
needed as part of the core, then perhaps we can have a tools-bundle.

To do this effectively using the Maven "way" - we might want to have 
each tool (in one "project") produce one jar (maven way:  each project 
<=> one jar), at a particular version level.  These would be available 
in the maven jar repository, and maven tooling could be used to fetch 
them.   Maven "assemblies" could then be used to package multiples of 
these into bigger packages of things.  A basic idea here would be that 
the version of the assembly would be on a different "schedule" than the 
components.  So someone downloading an assembled "bundle" would get 
parts, each of which had their own version number.  This is similar to 
what you get with other big projects that include jars from other 
sources.  The parts which are stable and not changing would not have 
their version numbers incremented in the assembled bundle.

-Marshall


Michael Baessler wrote:
> Marshall Schor wrote:
>> Thilo Goetz wrote:
>>  
>>> Hi Marshall,
>>>
>>> as usual, my view is pretty much the exact opposite ;-)
>>>
>>> First of all, I don't see the sense in creating yet another
>>> category.  To my mind, there's nothing wrong with having
>>> mature components in the sandbox.  The only thing I would
>>> consider is to move some sandbox components that are really
>>> important to people into the core.
>>>       
>> I think people might feel that the sandbox isn't a place to get
>> production-quality things, and I was hoping that some of these
>> components were production-quality :-)   
> I think Thilo raised a good point here. We still have an "empty 
> framework" that does not provide any linguistic functionality out of 
> the box. So maybe we should think about moving sandbox components that 
> are ready to use and are important for most of the UIMA users to the 
> core. We could than also provide some more out of the box analytics by 
> combining the components.
>
> For all the other Sandbox components that are ready to use but are not 
> relevant for most of the UIMA users we can consider to do a separate 
> release for each component. I guess the release cycles are larger for 
> those components so that we do not have so much Sandbox component 
> releases.
>
> Opinions?
>
> -- Michael
>
>
>