On Mon, 15 Dec 2014, Sergey Beryozkin wrote:
As a first step, I thought we'd still keep the same tika-parser jar, the
only difference would be what dependencies ended up in the bundle. If
the tika-bundle-pdf has no POI jars included in it, then the Microsoft
Office related parsers shouldn't register themselves.
It would mean that the "pdf bundle" would have the image, microsoft etc
parser code in them, but the parsers wouldn't be registered as their
dependencies wouldn't be there.
Not sure if this can/will work, but it would mean we can do cut-down
bundles + cut-down-maven-docs, without needing to change anything else.
If it proves popular, we can then re-visit the "giant tika parsers"
question, but if not it shouldn't change anything. Well, that's the
theory... :)
Sorry if I haven't completely understood the idea, I think there's definitely
something nice being suggested above, and it sounds to me as if the following
can be one possible realization of it, as a first step for example,
- add a tika-pdf module, this will be a bundle, so it will work as a jar and
as an OSGI bundle; the code for tika-pdf will be extracted (and removed) from
tika-parsers
Not quite - I forsee this being OSGi only for now. Tika Parsers project
would be unchanged, OSGi users could have tika (all) as now, or just
tika-pdf
- tika-parsers will get updated to depend on tika-pdf - hence users working
with tika-parsers won;t be affected
No, that's a possible phase 2 if it goes well. No change for non-OSGi
stuff. Non-OSGi users can see the OSGi build to work out what to include
and exclude if they want. (This means that we have a unit tested way to
see what you do/don't want, without affecting things for the simple Tika
users we get confused already with tika-core + tika-parsers)
- those users who want working with PDF only would ad tika-core + tika-pdf
dependencies only
OSGi users would pick tika + tika-parsers, or tika + tika-parsers-pdf, or
tika + tika-parsers-pdf + tika-parsers-mp3 if they want
OSGi is nicely contained, and fairly easy to unit test, so let's use that
to test out the idea! That also solves the CXF need. Once that works, and
once we have a tested way that everyone can see + understand, then someone
can try to make the case for phase II where we push it to the maven pom /
project level!
Nick
