Am 31.05.2013 um 10:18 schrieb Jörn Kottmann <[email protected]>: > I see, the users need to migrate their code over to uimaFIT 2.0.
Eventually they should, but they should be able to choose when they want to do that. They can also just stay with 1.4.0 as long as they want. Even when they choose to migrate, the transition can go in small steps. It's not necessary to convert everything at once. > The reason why I asked is that it would probably be nice if not everybody > has to migrate everything again when things are moved to the core. I think a migration every now and then is unavoidable. Without that, there cannot be evolution. Consider users of Lucene 2.x, which is not compatible with 3.x. I think it is entirely possible that some forms of migration and deprecation will also be necessary between different upcoming releases of uimaFIT. Some parts are already quite stable, but others are not. I've tried to put in as much change as possible now (as time permits) and change as little as possible to make migration smooth, also provided the legacy layer. It wasn't my intention in bringing uimaFIT to Apache to effectively bury it and stop evolving. And here the circle closes, because some evolvement will eventually entail deprecation and migration. When code from uimaFIT is moved to the core, in particular the annotations, uimaFIT may have to change as well. Consider we move the @ConfigurationParameter to core and also the ConfigurationParameterInitializer. That would allow UIMA to initialize parameters on annotated class fields. However, we do not migrate the full factory-infrastructure. uimaFIT will have to be changed to support the UIMA-core-@ConfigurationParameter in addition to the 2.0.0 version and the 1.4.0 version. That is, because the "defaultValue" field of this annotation is used at descriptor creation time, not at during initialization. Such things need to be considered as well. It may seem a good thing to move all annotations immediately to core and change uimaFIT already to accommodate for that. Then, however, I fear that a "lock" will be put on the annotations so that they cannot change anymore. Some of them may have to change still. I'm under the impression that its easier to blame uimaFIT for potentially incompatible changes and migration than to blame the entire core framework. It could be considered to move just a few, select and probably stable annotations like @ConfigurationParameter. But effectively, it wouldn't buy much, because when the other not-so-stable annotations are eventually moved, uimaFIT will still have to be adapted to support it. Finally, for the @ConfigurationParameter, there is at least one issue that I would like to see solved before it goes to the core, and which will not be solved for 2.0.0, and that is overriding of default values in sub-classes [1]. At least there should be a concept that is sufficiently discussed to assure that changes to the annotation are not necessary to implement this feature. -- Richard [1] http://code.google.com/p/uimafit/issues/detail?id=69 > On 05/31/2013 12:00 AM, Richard Eckart de Castilho wrote: >> Am 30.05.2013 um 23:27 schrieb Jörn Kottmann <[email protected]>: >> >>> On 05/30/2013 11:25 PM, Richard Eckart de Castilho wrote: >>>> uimaFIT 2.0.0 is backwards compatible with 1.4.0. >>> Sorry, wasn't aware of that. >> I'll briefly explain, just in case we understand different things >> by "backwards compatible". >> >> uimaFIT 2.0.0 behaves differently in some aspects than uimaFIT 1.4.0. >> There were several incompatible changes we had on the plate, but which >> we were always pushing ahead for the next major release. >> >> In addition, the package names have changed since the move to Apache, >> so uimaFIT 2.0.0 could never have served as a drop-in replacement. >> >> In order to smooth the transition for current uimaFIT users, in particular >> for those that rely on the old behaviour, uimaFIT 2.0.0 comes with a >> legacy support layer. This can be enabled optionally and then requires >> uimaFIT 1.4.0 on the classpath as well. >> >> The legacy module in uimaFIT 2.0.0 contains all the original tests >> from 1.4.0 testing for the original behavior with the original >> annotations but using the 2.0.0 code base. The test for 2.0.0 do >> test for the new behavior. >> >> uimaFIT 1.4.0 is not forward-compatible, meaning that the factory >> methods from uimaFIT 1.4.0 won't work very well with uimaFIT 2.0.0 >> components. If a descriptor was created with a 2.0.0 factory method, >> however, it will also run in 1.4.0. >> >> uimaFIT 2.0.0 is backward-compatible with the legacy layer in that >> sense that it understands all the 1.4.0 annotations and interprets >> them with the 1.4.0 behavior. Type auto-detection following the >> 1.4.0 conventions is supported as well. When a descriptor >> for a 1.4.0 component is created with 2.0.0, it will create >> the correct descriptor. >> >> Both versions can even be mixed in a project. The 1.4.0 factories >> can be used to create 1.4.0 component descriptions, the 2.0.0 >> factories can be used for 1.4.0 and 2.0.0 components. When >> external resources are used, these should be created with >> the same version as the component to which they are bound to. >> >> I may have missed something, but I'm pretty confident that this >> is working very well. Tests with DKPro Core and DKPro Lab have >> shown no issues so far. The uimafit-maven-plugin works just nice >> with the 1.4.0 version of DKPro Core as well. >> >> I've also started a "migration guide" [1], but I'll have to >> revisit that since some additional things have changed since >> then. >> >> Cheers, >> >> -- Richard >> >> [1] https://cwiki.apache.org/UIMA/migration-guide-1x-to-2x.html
