Support for the Data Service Specification

[laeubi]

Add a first basic implementation of the DataSourceFactory

[gotson]

@laeubi can you check the failing CI?

[laeubi]

@gotson as it complains about code formatting is ther an Eclipse format profile or something I can use to format the source code?

[gotson]

@gotson as it complains about code formatting is ther an Eclipse format profile or something I can use to format the source code?

You can use the Spotless plugin: mvn spotless:check and mvn spotless:apply

[laeubi]

Done!

[gotson]

This has no unit tests, is this feasible to add some ?

[laeubi]

I'll try to add test-cases here, but have first to check how sqlite tests are structured.

[gotson]

I've checked the issue you raised at osgi/osfgi-test and i think you framed it quite well: how to make it easier for maintainers that know nothing and have no particular interest in OSGI to gauge a PR and have confidence to merge it.

That probably will take a bit of time, but i think it's the right approach.

[laeubi]

@gotson it hase taken a bit longer than desired but now I finally was able to add a small test-case, do you like to review and give some feedback if that would suffice?

[gotson]

The more i think of it, the more i wonder whether this needs to be part of sqlite-jdbc. Could it not be part of a separate project that would offer that functionality only ? And if someone wants OSGi support they could add one more dependency in their pom.xml / build.gradle.

[laeubi]

As always there are many options but in general this has several drawbacks, as already described here:

• https://github.com/xerial/sqlite-jdbc/issues/737

1. The vendor has the best knowledge how to create and configure the participating objects.
2. Changes in the internal implementation, e.g. refactoring of class names can be reflected an managed easier in the original repository, extra project maybe impose extra restrictions / problems (e.g. in this case a project needs to either embeds the sqlite-jdbc or republish it to add appropriate OSGi metadata)
3. No gap between deployment of new version and connector code
4. For non-osgi users, this is completely transparent and the is no need for them to change, but OSGi users will be happy to not reinvent the wheel, the library can just be dropped inside a framework and seaming less integrate, for example with the JPA Specification.

Beside that an extra project always needs to be found, needs extra release management and so on, also having "official" support let people directly contribute to the project instead of potentially contribute to two projects.

[laeubi]

It seems I missed formatting the test code, fixed now ...