> So the JDBC+API+wrapped RI is a bundle that just works
I wish some OSGi expect chimed in and told us if such bundling is
workable in OSGi world.
> If there are further inconveniences in making the API+RI bundle the default, please specify.
1) I just do not see why you feel "using several dependencies" to be a
lot harder than "using all-in-one-bundle".
I agree it is a bit more work, but it is not a rocket science.
If user codes against JsonValue, then she expects to have that API in
the class path. I would say "jdbc driver" as a provider of "JSR353"
would violate the principle of least astonishment.
2) For instance: slf4j, log4j, logback do not have default bundles.
3) If each and every library bundles JSON API, we would get
LinkageErrors or similar errors soon. It is just bad when distinct jar
files contain "the same" class files. It is very painful when they end
up to contain _different_ class files.
4) Consider the other side of a coin.
What if we would want implementing IBM's JSONx later?
(https://twitter.com/danharper7/status/514822464673951744).
If we had some way of "adding custom getObject" via external
dependencies, that would be much easier since we would not have to
touch "core" part of the driver.
If we hard-code JSR353 into the core "just for convenience of a single
jar", then it won't help us adding new datatypes.
Vladimir
