Am 09.08.2013 um 23:20 schrieb Marshall Schor <[email protected]>: > On 8/9/2013 4:44 PM, Richard Eckart de Castilho wrote: >> Am 09.08.2013 um 21:42 schrieb Marshall Schor <[email protected]>: >> >>> The uima-fit parent pom says: property: uima-version = 2.4.1, should it say >>> 2.4.2? >> uimaFIT currently does not require 2.4.2, but it requires 2.4.1. The next >> version is likely to require 2.4.2 (or whatever is current then) due to >> changes enabled by UIMA-3143 [1]. I didn't plan to cram that in now. >> >> So there is no strict requirement on 2.4.2. Are you suggesting to depend on >> 2.4.2 because it's the latest bugfix release? > > So, this raises an interesting question, which we've grappled with before. If > uimaFIT is intended as an "add-on" to the UIMA SDK, and should work with > "several" versions, should the uimaFIT binary release actually include the > base > UIMA jars?
It might come as a surprise, but I actually don't have a strong opinion here ;) Personally, I'd be fine with just releasing via Maven Central and not even worry about wrapping up a binary release. Earlier binary releases of uimaFIT have included all the stuff. Since there are minimal dependencies, it's probably a good idea to include these minimal dependencies at least. We also had discussions in uimaFIT earlier whether we should always depend on the latest and greatest or on the minimally required versions. At the time it was resolved not to chase the latest and greatest and be rather conservative. > We first packaged UIMA-AS, an add-on to base UIMA, as just having the added > stuff. But we found that users found that inconvenient, and wanted it > "bundled". So we switched to including base UIMA with it. (And in that > binary > distro, we also include the base UIMA javadocs, suitably renamed to avoid > collision). I think that's not suitable for uimaFIT. > Here, your packaging is set up to include the base uima jars (at least, most > of > them - it's missing the following: uima-adapter-soap, uima-adapter-vinci, > uima-document-annotation, uimaj-bootstrap). If you're including UIMA jars as > a > convenience, you might want to include *all* of the jars, and in that case, > because of the buggyness of uima 2.4.1, I would suggest including 2.4.2 :-) . > If you expect the user to separately get base UIMA and install uimaFit on top, > then I guess I wonder why would there be in uimaFIT binary distribution *any* > inclusion of (some) UIMA jars? Hm. A difference between the Maven dependencies and the binary release may be sensible. E.g. have uimaFIT *depend* on 2.4.1, but include 2.4.2 (and possibly a more recent Spring version) in the binary release. Should be possible be overriding the versions in the aggregator pom. -- Richard
