Refactor JDBC plugins

[dmikurube]

( Cc: @embulk/core-team )

Hi,

(Note that nothing has been decided. This is just sharing my thoughts.)

I am thinking about refactoring JDBC plugins like the following.

• Not to inherit the base AbstractJdbcInput/OutputPlugin class in embulk-input/output-jdbc, but to inherit just Embulk's base SPI InputPlugin/OutputPlugin.
• Share JDBC features as a standalone utility library like embulk-util-jdbc.
• (Nice to have) Modify the Changelog style to Git annotation tag-based, not the ChangeLog file.
• (Nice to have) Split plugin repositories for each after the refactoring is done.

These are because:

• Some recent RDB(-like) systems provide not-only SQL interfaces, such as S3 COPY in Redshift. To implement features flexibly with such interfaces, we may want to have JDBC things just as a tooling, not as the fixed center of these plugins.
• Not only input/output plugins wanted to use JDBC toolings, such as embulk-filter-calcite. It needed to depend on embulk-input-jdbc, but it's a little bit awkward.
• Many of recent updates in JDBC plugins are usually for one of them, not for all JDBC plugins.

However, as we can easily imagine, it would be a big change that impacts a lot of things, including other JDBC plugins out of https://github.com/embulk/ . So, I wanted to hear your thoughts.

What do you think? Any comments are welcome.

[dmikurube]

Moved this to another discussion category: "Contributors wanted"