Updated classpath in schema-registry-run-class to reflect changes in …

[granders]

@miguno Mind taking a quick look? I noticed that the schema registry start script was failing due to SchemaRegistryMain no longer being in the classpath.

My primary question here is whether this is enough, or should we add other modules?
E.g. in pom.xml I now see

        <module>core</module>
        <module>client</module>
        <module>avro-serializer</module>
        <module>json-serializer</module>
        <module>avro-converter</module>
        <module>package-schema-registry</module>
        <module>package-kafka-serde-tools</module>

[ConfluentJenkins]

Refer to this link for build results (access rights to CI server needed):
http://jenkins.confluent.io/job/schema-registry-pr/69/
Test PASSed.

[miguno]

LGTM.

I assume you sent this PR because schema registry caused issues for muckrake? The packaged (e.g. rpm) version of schema registry works fine without this PR because it pulls in jars via a different for-loop in schema-registry-run-class.

FYI: I'll merge your PR but will keep this thread open for the follow-up discussion.

My primary question here is whether this is enough, or should we add other modules?

The jar directory you updated in your PR includes the code of the following modules (I skip the package-* modules as these don't contain code themselves):

        <module>core</module>
        <module>client</module>

What is not included is:

        <module>avro-serializer</module>
        <module>json-serializer</module>
        <module>avro-converter</module>

My question is now quite similar to yours: Does schema-registry at run-time (think: production) need any of the Avro/JSON serdes depending on the user's setup? Neither core/pom.xml nor client/pom.xml do require the serdes at compile time. /cc @ewencp .

[miguno]

It looks like we don't need any further changes, @granders .