On 12/18/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
I think what we have is annotator A might have a version of types for it (T/A) and annotator B might have a version of types for it (T/B). The "assembly" of A and B has a process whereby T/A and T/B are "merged", and a new T/A&B is created. This seems different form the Xerces example. It's not ncesessarily a "newer" versus "older" thing, for UIMA assemblies.
To me it's very similar, the difference being that in most cases it would be easier to merge T/A and T/B than it would be the merge Xerces versions X and Y. But in both cases there are additional options other than merging: 1) If one version is newer than another and backwards compatible then you can just use the newer one. I think this can be common in UIMA, where someone has extended an existing type. 2) You can use separate ClassLoaders for the two components so that they can each use their own version of the class. This would also mean that they can't share the JCAS cover objects directly, but would each need their own instance. But that seems doable, and perhaps simpler than the automatic merge and more "normal" in the Java world.
I agree this is a good goal. It seems achievable with some "automation" introduced into the assembly step. > This seems particularly important for applications that host arbitrary > UIMA analytics. End users want to grab the latest, greatest annotator > and drop it in. This should work smoothly, or UIMA isn't meeting one > of its most important goals. I agree. Perhaps we should figure out what (if anything) is inhibiting this, and see if it can be be addressed. One concept might be to require JCas source/class files to be packaged in a particular way, and to improve the "merge" logic to cover more cases (and report on the cases where it fails and a "manual" merge step might be needed). I think in most pragmatic cases it will work fine "automatically".
What about the following adjustment to my original proposal: We explicitly document that JCAS and "feature extension" are not compatible in the *current* version of UIMA, but that we may figure out some way to make them compatible in the future. -Adam
