uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [VOTE] accept CAS Editor (tae) bulk contribution into Sandbox?
Date Thu, 15 Feb 2007 11:48:06 GMT
Jörn Kottmann wrote:
>>
>> I have checked in your code to the UIMA sandbox. The URL is: 
>> http://svn.apache.org/repos/asf/incubator/uima/sandbox/trunk/CasEditor/
>>
>> I created only one project called CasEditor and hope that the eclipse 
>> plugins you have work also with a single eclipse project layout. If 
>> not, we have to separate them again.
>> I also created a initial pom.xml based on the uima eclipse plugins, 
>> but there are still some open items to work on (final names, 
>> dependencies...).
>
> This will brake some smaller things, but nothing which cannot be 
> changed. Maybe this will cause some
> troubles for the plugin tests, but I am not sure.
>
> What is the reason to merge them ?
>
> I think it is now difficult to get it back working since you have done 
> a few changes at once.
> New namespace for all classes, porting from IBM Uima to Apache Uima, 
> merging and
> maven support.
>
> In my opinion the fastest way to get everything back working is that I 
> do these changes by myself
> and then attach at it again to the JIRA issue (as patch ?).
>
> I have to do the following task to complete the contribution:
>
> + Change namespace
> + remove author and cvs tags
> + Port to apache uima
> + Maybe merge the plugins
> + add maven support
>
> What do you think ?

Hi, Jörn,

Here are some reasons to package things together into fewer plugins: it 
makes it easier for users to manage / think about, it makes it  maybe 
easier for developers if the code for one thing is all together, and if 
they're on the same release cycle. 

Some reasons to package things separately into multiple plugins: if the 
parts are reused by other, independently developed plugins, if the parts 
are on different release mechanisms (being released at different times), 
if the parts are large and users might want to "customize" their install 
by not installing some parts.

Eclipse plugins are moving more toward reducing complexity by having 
fewer plugins.  I've heard more than one person say the example set by 
"EMF" of having many plugins is now considered a poor practice, causing 
more difficulties that it solves.

-  -  -

The normal "Apache Way" for work is to incrementally move forward - so 
in that spirit, it might be better to take what's now in our SVN and 
improve it.  If that can work for you, great.  If not, that's OK - the 
most important part is having you contributing!

-Marshall

Mime
View raw message