UIMA Addons releases

[Tommaso Teofili <to...@gmail.com>]

Hi all,

I just started reviewing UIMA addons single components in order to release
them soon; so now I wonder if we should keep the last decision of releasing
UIMA Addons as a whole or rather start releasing single components (e.g.
WhitespaceTokenizer, HMMTagger, etc.).

At the moment I'd see the latter as the better option because:
a) some of the components have not been touched since last release (2.3.1)
b) users / devs usually need to get single components (e.g. via Apache
Maven) rather than the whole package

On the contrary the bad would be that users / devs cannot just download a
single addons package with the latest releases of each component.

To catch up with this latest concern an idea could be to release single
components first and then (on a regular basis, e.g. every 6 months / once
each component has a new release / etc.) release the addons package as just
the aggregation of single components' latest releases.

What do you think?

Have a nice day,
Tommaso

Re: UIMA Addons releases

[Tommaso Teofili <to...@gmail.com>]

2013/1/11 Jens Grivolla <j+...@grivolla.net>

> I agree that individual addons are mostly independent of UIMA releases,
> but it is convenient to know that when you're using UIMA-2.4.0 you can
> depend on e.g. ConceptMapper-2.4.0. Maybe that would be handled by your
> periodic releases, i.e. just tagging all components with a common release
> number that relates to the current UIMA release so it's easy to find a
> compatible version.
>

right, it would be assumed that an addon version 2.4.x is tight to UIMA SDK
2.4.x (even if eventually compatible with lower versions).


>
> Then again, it's not that much work to check for dependency mismatches
> when including an addon in your project via maven. Given that uimaj-core
> would be declared as "provided" the dependency is not transitive, right?


right.


> Would it show up then if an addon you are using depends on a newer version
> of uimaj-core than the one you are using (or an older one if there are
> incompatible changes)?
>

as long as they're backward compatible (which should be true for minor
version upgrades) there wouldn't be any "show ups" at runtime.
Therefore I think addons should just keep using uimaj-core 2.3.x for their
2.3.x versions, and 2.4.x for their 2.4.x versions, maybe as you suggest
with the uimaj-core declared as scope provided.


>
> Bye,
> Jens


Thanks,
Tommaso


>
>
> On 01/11/2013 08:48 AM, Tommaso Teofili wrote:
>
>> Hi all,
>>
>> I just started reviewing UIMA addons single components in order to release
>> them soon; so now I wonder if we should keep the last decision of
>> releasing
>> UIMA Addons as a whole or rather start releasing single components (e.g.
>> WhitespaceTokenizer, HMMTagger, etc.).
>>
>> At the moment I'd see the latter as the better option because:
>> a) some of the components have not been touched since last release (2.3.1)
>> b) users / devs usually need to get single components (e.g. via Apache
>> Maven) rather than the whole package
>>
>> On the contrary the bad would be that users / devs cannot just download a
>> single addons package with the latest releases of each component.
>>
>> To catch up with this latest concern an idea could be to release single
>> components first and then (on a regular basis, e.g. every 6 months / once
>> each component has a new release / etc.) release the addons package as
>> just
>> the aggregation of single components' latest releases.
>>
>> What do you think?
>>
>> Have a nice day,
>> Tommaso
>>
>>
>
>

Re: UIMA Addons releases

[Jörn Kottmann <ko...@gmail.com>]

On 01/11/2013 11:24 AM, Jens Grivolla wrote:
> I agree that individual addons are mostly independent of UIMA 
> releases, but it is convenient to know that when you're using 
> UIMA-2.4.0 you can depend on e.g. ConceptMapper-2.4.0. Maybe that 
> would be handled by your periodic releases, i.e. just tagging all 
> components with a common release number that relates to the current 
> UIMA release so it's easy to find a compatible version. 

Maybe we should just specify the minimum UIMA SDK version in the poms,
most of them probably don't need the latest UIMA version to run.

Jörn

Re: UIMA Addons releases

[Jens Grivolla <j+...@grivolla.net>]

I agree that individual addons are mostly independent of UIMA releases, 
but it is convenient to know that when you're using UIMA-2.4.0 you can 
depend on e.g. ConceptMapper-2.4.0. Maybe that would be handled by your 
periodic releases, i.e. just tagging all components with a common 
release number that relates to the current UIMA release so it's easy to 
find a compatible version.

Then again, it's not that much work to check for dependency mismatches 
when including an addon in your project via maven. Given that uimaj-core 
would be declared as "provided" the dependency is not transitive, right? 
Would it show up then if an addon you are using depends on a newer 
version of uimaj-core than the one you are using (or an older one if 
there are incompatible changes)?

Bye,
Jens

On 01/11/2013 08:48 AM, Tommaso Teofili wrote:
> Hi all,
>
> I just started reviewing UIMA addons single components in order to release
> them soon; so now I wonder if we should keep the last decision of releasing
> UIMA Addons as a whole or rather start releasing single components (e.g.
> WhitespaceTokenizer, HMMTagger, etc.).
>
> At the moment I'd see the latter as the better option because:
> a) some of the components have not been touched since last release (2.3.1)
> b) users / devs usually need to get single components (e.g. via Apache
> Maven) rather than the whole package
>
> On the contrary the bad would be that users / devs cannot just download a
> single addons package with the latest releases of each component.
>
> To catch up with this latest concern an idea could be to release single
> components first and then (on a regular basis, e.g. every 6 months / once
> each component has a new release / etc.) release the addons package as just
> the aggregation of single components' latest releases.
>
> What do you think?
>
> Have a nice day,
> Tommaso
>