Change modifier from private to protected

[legiangthanh]

In this PR, I propose we change private to protected, There is some reason for this PR

• Current private methods make it hard to customize
• We add the flexibility for other implementor to overwrite this method
• The old version (0.5.3) uses protected, but the newest version changed it to private. I think changing back to protected will make it more backward compatible.

[dmikurube]

It was protected just because it had another subproject embulk-input-riak_cs, but it has gone because Riak CS is no longer actively developed. Then protected got no longer needed. There is no compatibility issues.

Can you explain more concrete use-cases that "the flexibility for other implementor" is more useful?

If "flexibility" is always more important, we may make everything public, right? But, we usually don't do it indeed because controlling visibility of classes / methods is important to keep things maintainable. We need reasons convincing maintainers to break the visibility control.

[legiangthanh]

In the latest version, almost methods in S3FileInputPlugin.java is private which makes we can not customize the behavior of this class. It means we only use this plugin the way it is implemented without any customizing. For example, In our case, we need to override getCredentialsProvider method to add some validation and reject the unused authentication method.

For backward compatibility, I think we released this plugin in the past, we should keep the contract intact as much as possible because we don't know how others use this plugin.

[dmikurube]

It means we only use this plugin the way it is implemented without any customizing.

Yes, that is the expected use of Embulk plugins. Embulk plugins do not expect to be used as a library from other things. OSS Embulk plugins do not care about such "backward compatibility". embulk-input-riak_cs was managed in this same repo, and everything was under control. We have never provided the method as a public contract.

I'm asking you to describe the use-case why it is better here to overcome the basic principle that "Embulk plugins do not expect to be used as a library from other things".

[dmikurube]

Hint:

In our case, we need to override getCredentialsProvider method to add some validation and reject the unused authentication method.

In other words, why don't you contribute that part to this open-sourced embulk-input-s3? Explaining the reason why yon don't contribute it may explain the reason why such customizability would be useful for public users / developers, too.