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 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
