You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2011/08/17 16:10:19 UTC
preparing for 2.3.2 release of base UIMA sdk
I'd like to do a release of the base UIMA SDK soon.
We've tried the alternative structure, of putting a top-level pom in the
directory above the projects, for the addons. This structure is more
conventional for Maven projects, but creates a bit of "noise" in the Eclipse IDE
(the projects appear twice).
I'm personally comfortable with moving to the more conventional structure; would
others object if I convert the base UIMAJ project structure to that style?
-Marshall
Re: preparing for 2.3.2 release of base UIMA sdk
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
Hello Marshal,
your point is well taken. I'll go a bit into detail now. My intention was this:
1) if a spring context provides a bean by the name of the resource use that
2) use the default UIMA logic to initialize the resource
By subclassing, this works nice. First I add all beans from the context to the mInternalResourceRegistrationMap. Then I call super.initializeExternalResources(...), which is written so that it then only instantiates all resources with a name that has not yet been registered.
Instead of subclassing, it would be possible to implement a completely new ResourceManager, but that would mean to copy lots of code from the ResourceManager_Impl and change just a minor detail. It would also be possible implement a delegation pattern, remove those resources and resource bindings that could be covered by the Spring context from the ResourceManagerConfiguration instance before passing it on to the delegate ResourceManager, but that would make quite a bit more complex. It is definitely worth considering in the long run.
The main point though is that, independent of subclassing vs delegation, there is something very odd here. The mInternalResourceRegistrationMap is protected, but the type of the instances inside it (ResourceRegistration) are package private. This seems quite pointless because there is no way for a subclass to make use of mInternalResourceRegistrationMap in that manner. So either mInternalResourceRegistrationMap should be package private as well, or ResourceRegistration should be protected. I'd opt for the latter because most parts of the ResourceManager_Impl are protected (and because it makes my code simpler for the time being).
Even though delegation provides a better separation that subclassing, is it necessary for a framework to make it particularly difficult to use subclassing? Shouldn't it be the choice of the developer to couple tightly or loosely?
Best regards,
Richard
Am 18.08.2011 um 22:29 schrieb Marshall Schor:
> Hi Richard,
>
> before we do something here, I'm wondering if you've considered a delegation
> model, rather than subclassing.
>
> Subclassing tends to create a rather tight coupling between a class and its
> subclass, in terms of maintenance and changes, while delegation doesn't; several
> articles I've seen seem to favor delegation over inheritance.
>
> Would a delegation model work in this case for what you want to experiment with?
>
> -Marshall
>
> On 8/18/2011 2:29 AM, Richard Eckart de Castilho wrote:
>> Hi,
>>
>> would you mind addressing https://issues.apache.org/jira/browse/UIMA-2102 before the 2.3.2 release?
>>
>> Cheers,
>>
>> Richard
>>
>> Am 17.08.2011 um 17:37 schrieb Marshall Schor:
>>
>>> ok, I'll do this restructuring, under
>>> https://issues.apache.org/jira/browse/UIMA-1967
>>>
>>> -Marshall
>>>
>>> On 8/17/2011 10:21 AM, Jörn Kottmann wrote:
>>>> On 8/17/11 4:10 PM, Marshall Schor wrote:
>>>>> I'd like to do a release of the base UIMA SDK soon.
>>>>>
>>>>> We've tried the alternative structure, of putting a top-level pom in the
>>>>> directory above the projects, for the addons. This structure is more
>>>>> conventional for Maven projects, but creates a bit of "noise" in the Eclipse IDE
>>>>> (the projects appear twice).
>>>>>
>>>>> I'm personally comfortable with moving to the more conventional structure; would
>>>>> others object if I convert the base UIMAJ project structure to that style?
>>>>>
>>>> I am also +1, because it makes things easier.
>>>>
>>>> Jörn
>>>>
>> Richard Eckart de Castilho
>>
Richard Eckart de Castilho
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: preparing for 2.3.2 release of base UIMA sdk
Posted by Marshall Schor <ms...@schor.com>.
Hi Richard,
before we do something here, I'm wondering if you've considered a delegation
model, rather than subclassing.
Subclassing tends to create a rather tight coupling between a class and its
subclass, in terms of maintenance and changes, while delegation doesn't; several
articles I've seen seem to favor delegation over inheritance.
Would a delegation model work in this case for what you want to experiment with?
-Marshall
On 8/18/2011 2:29 AM, Richard Eckart de Castilho wrote:
> Hi,
>
> would you mind addressing https://issues.apache.org/jira/browse/UIMA-2102 before the 2.3.2 release?
>
> Cheers,
>
> Richard
>
> Am 17.08.2011 um 17:37 schrieb Marshall Schor:
>
>> ok, I'll do this restructuring, under
>> https://issues.apache.org/jira/browse/UIMA-1967
>>
>> -Marshall
>>
>> On 8/17/2011 10:21 AM, Jörn Kottmann wrote:
>>> On 8/17/11 4:10 PM, Marshall Schor wrote:
>>>> I'd like to do a release of the base UIMA SDK soon.
>>>>
>>>> We've tried the alternative structure, of putting a top-level pom in the
>>>> directory above the projects, for the addons. This structure is more
>>>> conventional for Maven projects, but creates a bit of "noise" in the Eclipse IDE
>>>> (the projects appear twice).
>>>>
>>>> I'm personally comfortable with moving to the more conventional structure; would
>>>> others object if I convert the base UIMAJ project structure to that style?
>>>>
>>> I am also +1, because it makes things easier.
>>>
>>> Jörn
>>>
> Richard Eckart de Castilho
>
Re: preparing for 2.3.2 release of base UIMA sdk
Posted by Richard Eckart de Castilho <ec...@tk.informatik.tu-darmstadt.de>.
Hi,
would you mind addressing https://issues.apache.org/jira/browse/UIMA-2102 before the 2.3.2 release?
Cheers,
Richard
Am 17.08.2011 um 17:37 schrieb Marshall Schor:
> ok, I'll do this restructuring, under
> https://issues.apache.org/jira/browse/UIMA-1967
>
> -Marshall
>
> On 8/17/2011 10:21 AM, Jörn Kottmann wrote:
>> On 8/17/11 4:10 PM, Marshall Schor wrote:
>>> I'd like to do a release of the base UIMA SDK soon.
>>>
>>> We've tried the alternative structure, of putting a top-level pom in the
>>> directory above the projects, for the addons. This structure is more
>>> conventional for Maven projects, but creates a bit of "noise" in the Eclipse IDE
>>> (the projects appear twice).
>>>
>>> I'm personally comfortable with moving to the more conventional structure; would
>>> others object if I convert the base UIMAJ project structure to that style?
>>>
>>
>> I am also +1, because it makes things easier.
>>
>> Jörn
>>
Richard Eckart de Castilho
--
-------------------------------------------------------------------
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab
FB 20 Computer Science Department
Technische Universität Darmstadt
Hochschulstr. 10, D-64289 Darmstadt, Germany
phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117
eckartde@tk.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: preparing for 2.3.2 release of base UIMA sdk
Posted by Marshall Schor <ms...@schor.com>.
ok, I'll do this restructuring, under
https://issues.apache.org/jira/browse/UIMA-1967
-Marshall
On 8/17/2011 10:21 AM, Jörn Kottmann wrote:
> On 8/17/11 4:10 PM, Marshall Schor wrote:
>> I'd like to do a release of the base UIMA SDK soon.
>>
>> We've tried the alternative structure, of putting a top-level pom in the
>> directory above the projects, for the addons. This structure is more
>> conventional for Maven projects, but creates a bit of "noise" in the Eclipse IDE
>> (the projects appear twice).
>>
>> I'm personally comfortable with moving to the more conventional structure; would
>> others object if I convert the base UIMAJ project structure to that style?
>>
>
> I am also +1, because it makes things easier.
>
> Jörn
>
Re: preparing for 2.3.2 release of base UIMA sdk
Posted by Jörn Kottmann <ko...@gmail.com>.
On 8/17/11 4:10 PM, Marshall Schor wrote:
> I'd like to do a release of the base UIMA SDK soon.
>
> We've tried the alternative structure, of putting a top-level pom in the
> directory above the projects, for the addons. This structure is more
> conventional for Maven projects, but creates a bit of "noise" in the Eclipse IDE
> (the projects appear twice).
>
> I'm personally comfortable with moving to the more conventional structure; would
> others object if I convert the base UIMAJ project structure to that style?
>
I am also +1, because it makes things easier.
Jörn
Re: preparing for 2.3.2 release of base UIMA sdk
Posted by Tommaso Teofili <to...@gmail.com>.
2011/8/17 Marshall Schor <ms...@schor.com>
> I'd like to do a release of the base UIMA SDK soon.
>
> We've tried the alternative structure, of putting a top-level pom in the
> directory above the projects, for the addons. This structure is more
> conventional for Maven projects, but creates a bit of "noise" in the
> Eclipse IDE
> (the projects appear twice).
>
> I'm personally comfortable with moving to the more conventional structure;
> would
> others object if I convert the base UIMAJ project structure to that style?
>
I am +1 for this change.
Tommaso
>
> -Marshall
>