On 12/19/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
How about: We explicitly document that if "feature extension" is used with
JCas, you need to
(a) package type systems and the JCas generated classes
separately from other packagings, and
(b) be willing to re-run JCasGen when
your type package is combined with others, and
(c) if hand-modifications are
done to the generated JCas classes, then that version of the source must be
available when running JCasGen and the "merge" option must be used.
Limitation: if multiple versions of the JCasGen generated sources were
independently
hand-modified, then the assembler has to hand-merge the resulting source
for those
types to pick up all the hand-modifications into the result.
Can we put all that in a warning dialog that pops up from the CDE and
JCasGen? That ought to be enough to discourage users from doing this.
:)
But I would say that (b) should really say: "Be sure that all the
users of your component are willing and have the know-how to run
JCasGen when they combine your component with others."
But the trouble is that I think that would be a dangerous assumption
for any annotator developer to make.
> 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".
I'm wary of the complexity that's introduced when we have to muck with
source code at assembly time. In principle I could see how we can
make this work if annotators always included their JCAS cover classes
in source form (if they had any extensions) in a certain specified wa
of packaging, and if had an enahcned merge utility (like what's in
SVN) that could merge source files as long as they didn't have
overlapping edits, and we required that this be done as part of
aggregate assembly (so assembly now requires using a tool or invoking
an API, and can no longer be safely done by working with XML). But
I'm not sure the added complexity is worth the gain, versus the
alternative of asking people to use typical programming practices to
manage their JCAS classes as they would other shared Java code (i.e.,
people have to negotiate to create the one standard version that they
can all share).
Anyway, I doubt we're solving this problem for v2.1, so in the short
term what can we do about it? And specifically, what can we do about
DocumentAnnotation?
-Adam
