Nick, I see now why it was done: we use `Embed-Dependency` for tika-bundle in 1.x and for tika-parser-*-bundle in 2.x so it produces fat/uber jar with some dependencies inlined in them. This is unsuitable for non-OSGi builds.
So I withdraw my "bright" idea about merging corresponding modules and bundles. Concern about testing is pointless because bundles only contain OSGi integration tests which aren't to be run when `mvn test` is called and don't affect unit tests at all. If tests were the only issue, there would be no problem at all: each `BundleIT` just starts embedded OSGi container as any other junit test can start e.g. cxf jax-rs test container, arquillian container etc. ср, 29 мар. 2017 г. в 11:54, Nick Burch <[email protected]>: > On Wed, 29 Mar 2017, Konstantin Gribov wrote: > > I've been surprised by such separation, what was the reason to separate > > them? > > I think partly history (we split in 1.x), partly how the split was done > (osgi folks amongst the most keen), and partly a desire not to have > non-OSGi users getting a load of things they didn't need / might confuse > them? > > > If there's no blockers I'd prefer to merge them: OSGi headers in > > MANIFEST.MF do not affect artifact usage in usual Java SE environment > > and it reduces number of artifacts drastically and simplifies dependency > > management. > > Just adding a few headers to the manifest would be fine with me, that > seems low-risk and low-impact > > Not sure on the unit testing front - we'd want the current parser unit > tests to run fully outside OSGi, plus we want some other tests to run > within an OSGi environment to ensure the bundle's fine. Can we easily do > both if we merged? or would we want to merge the headers but leave the > OSGi-specific tests in another module? > > Nick > -- Best regards, Konstantin Gribov
