Issue 45: Split serializers into format specific libraries

[shiveshr]

Change log description
Split serializers into format specific libraries

Purpose of the change
Fixes #45

What the code does
Breaks down serializer library into 4 different libraries -

1. shared -- contains all the base classes and interfaces and codecs.
2. avro -- serializers for avro
3. protobuf -- serializers for protobuf
4. json -- serializers for json

Then there is the existing serializers library which depends on each of these individual libraries.
One subtle thing we do is, we have kept the package structure identical for all three new modules as the original instead of putting avro serializers in an avro package.
This allows us to keep our classes accessible at package private access level rather than make them public.
Only the factories and the user interfaces are public.
However, this also means the classes across these three modules cannot share the same name if they are to be referenced in the combined serializers module.
Removed split package as it is not supported by more recent java versions.

How to verify it
All existing tests should pass.

[shiveshr]

@fpj i have renamed the packages to keep all serializers for avro, protobuf and json in following packages:
io.pravega.schemaregistry.serializer.<module-name>.impl

[fpj]

@shiveshr one thing that occurred to me while reviewing the recent changes: will we ever want to have serializers for other systems or is it going to be for Pravega and that's it? If we consider that we can have serializers for other systems, then what would be the package structure in that case?

[fpj]

Another question, is it worth having an uber artifact with everything in addition to the individual ones for the different serialization schemes?

[fpj]

Another question, is it worth having an uber artifact with everything in addition to the individual ones for the different serialization schemes?

Never mind, you have answered this question in this other thread:

https://github.com/pravega/schema-registry/pull/84/files#r460948568

[shiveshr]

one thing that occurred to me while reviewing the recent changes: will we ever want to have serializers for other systems or is it going to be for Pravega and that's it? If we consider that we can have serializers for other systems, then what would be the package structure in that case?

Although the serializers interface that we implement is the interface that pravega applications expect, the interface itself is quite generic.
It has serialize and deserialize methods and can actually be used outside of pravega applications too.

[ravisharda]

A number of initializations and unrelated assert statements indicate that this test has multiple responsibilities. Please break it down into separate tests.

[fpj]

I'll approve this one assuming a couple of thigs:

1- We won't be making deep changes to the existing PR. If we end up making deep changes, then please reset my review so that I can review it again.
2- We will soon complete publishing snapshots so that we can see more clearly how it looks like.