uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <eck...@ukp.informatik.tu-darmstadt.de>
Subject Re: Contributing uimaFIT to Apache UIMA
Date Thu, 31 May 2012 20:02:52 GMT
Hello,

thank you for your feedback. 

>>> 1) uimaFIT already has an established user base.  This means it will
>>> have backwards-compatibility requirements for that community.  This will
>>> be a factor in how we proceed to integrate the concepts into UIMA.

We (uimaFIT developers) would like a transition to Apache to cause minimal
hassle for existing users. If possible, it should be limited to updating the
imports for a new package name and changing a dependency/jar.

>>> 1a) If we find, thru a bigger community discussion / involvement, other
>>> directions we want to align the uimaFIT concepts with, it seems we might
>>> end up with both an "old-style" uimaFIT - supporting the existing user
>>> base, paying close attention to backwards compatibility and/or
>>> migration, and a (likely incompatible) new-style integration of the
>>> uimaFIT concepts into UIMA.

We'd prefer uimaFIT to remain as-is for the transition. As has already been
suggested and commented upon, some features of uimaFIT may eventually end
up in the core UIMA framework. Currently I would think that this might be
a new-style UIMA then. At this point, uimaFIT and UIMA should both continue
to support a legacy code base for some time. However, it seems to me that
this is looking to far into the future at the moment. 

>>> 2) Bringing the code for uimaFIT into the UIMA project: It seems it
>>> would initially go into the Sandbox until IP issues (if any) are
>>> resolved, and then be moved to the add-ons, since it is already a mature
>>> thing with users.  If we then go down the path envisioned in 1a), we
>>> would have some kind of parallel development in UIMA of the concepts.
>> I don't understand the bit about the sandbox.  We'll need a code grant,
>> which we'll only accept if we're satisfied there are no IP issues.  It
>> won't go into subversion before then, and afterwards we can stick it
>> wherever we want.  Right?
> 
> Yes, I guess I was thinking it might need some "work" before it was ready to get "released".
 If this work would complete before the next time we wanted to release all of the add-ons
(which, by the way, we might not do - we have the option of releasing just individual pieces),
then it could go directly into add-ons.

Thank you for bringing this up. Assuming that we can satisfy your requirements
regarding the IP clearance, it would be great if uimaFIT could go directly to
the add-ons.  

Some work may be required to make a transition, but in general uimaFIT is
extremely solid and has a very good test coverage.  From our side, are no
reservations against making a new release any time soon. In fact, we have
already cleaned up several things in the last few months with an upcoming
contribution in mind.

It would be appreciated if uimaFIT could continue with its own release cycle,
that is, uimaFIT releases may be more frequent than UIMA SDK releases.

>>> Here's one example of a possible future alternative:  uimaFIT uses
>>> special files to collect type system description references together
>>> where they can be found by convention.  We have previously been looking
>>> into various approaches to better manage issues around classpaths (we
>>> currently have PEARs), based on OSGi support, including hooking up with
>>> repositories (the idea being that UIMA components could live in Maven
>>> repositories, and be "reusable" by reference, using the Maven schemes of
>>> identifying artifacts by version).  A key part of this is the "version"
>>> management.  As we go forward, we might find some interesting
>>> integrations of type system information that is well aligned with these
>>> kinds of conventions.

[taking off uimaFIT hat, putting on DKPro Core hat]

Type-system detection is a key element in reducing the boiler plate when working
with UIMA using uimaFIT. The mechanism was first developed in the context of
DKPro Core and contributed to uimaFIT because we (UKP Darmstadt) felt it was
very basic and useful for other people to have. Currently, new mechanisms
similar to you describe them above are being developed in the context of
DKPro Core. We work towards another light-weight solution using Maven, but
without OSGi. So far, we have not had real issues that require classloader
isolation. 

[switching back to uimaFIT hat]

>>> 3) If we "open up" the discussion around uimaFIT-inspired improvements
>>> to UIMA, I can see pro/con arguments for moving uimaFIT to Apache:
>>> 
>>> 3a1) Pro: It would require the IP "vetting" of the uimaFIT code base,
>>> and thus make that code more re-usable inside UIMA.

uimaFIT is already under the Apache License. I suppose after the IP clearance
is through, parts could easily be integrated into core. Any advice as to IP
problems that may crop up is appreciated.

>>> 3a2) Pro: It could likely lead to some new committers :-)

Definitely. We do want to continue developing uimaFIT. The development of
uimaFIT follows a certain spirit, that we want to maintain beyond the formal
contribution. There is also a number of issues on our to do list. I suspect
that it will mostly be me doing active coding. Recently, Philip and Steven
do less coding, but still contribute with valuable comments.

>>> 3a3) Pro: It would likely result in increased focus/attention on making
>>> progress in this area.
>>> 
>>> 3b1) Con: It may confuse UIMA users somewhat, as to what we're doing.

As long as uimaFIT remains a separate module, it should not confuse users too
much. With a more official status, we expect and hope that more people will use
and comment on uimaFIT and its concepts. Eventually, this should lead to a
point that integrating its concepts into the core should cause little
confusion amongts the users.

>>> I guess this is all normal, and goes along under the category "managing
>>> change" :-).
>> Why don't we take this one step at a time?  First, a statement from the
>> UIMA developers if they intend to accept this contribution.  I've heard
>> no negative voices so far.  Second, the formal code grant and acceptance
>> vote.  Third, a uimaFIT release as part of the next UIMA release.

Please go ahead. We shall kick-off the IP clearance process once a formal
vote in favor of the contribution has been made.

>> That seems pretty straightforward to me.  When we have all that under
>> our belts, we can start discussing if and how we want to move uimaFIT
>> closer to the core.

Mind that our intention not to hand uimaFIT off because we are done with it.
We definitely intent that at least one of these "belts" you are talking about
is around our waists.

Best,

-- Richard

-- 
------------------------------------------------------------------- 
Richard Eckart de Castilho
Technical Lead
Ubiquitous Knowledge Processing Lab (UKP-TUD) 
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
eckart@ukp.informatik.tu-darmstadt.de 
www.ukp.tu-darmstadt.de 
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
------------------------------------------------------------------- 







Mime
View raw message