aah, that makes sense

On Sun, Sep 22, 2019 at 6:11 PM Vinayakumar B <vinayakum...@apache.org>
wrote:

> Thanks Steve.
>
> Idea is not to shade all artifacts.
> Instead maintain one artifact ( hadoop-thirdparty) which have all such
> dependencies ( com.google.* may be), add  this artifact as dependency in
> hadoop modules. Use shaded classes directly in the code of hadoop modules
> instead of shading at package phase.
>
> Hbase, ozone and ratis already following this way. The artifact (
> hadoop-thirdparty) with shaded dependencies can be maintained in a separate
> repo as suggested by stack on HADOOP-13363 or could be maintained as a
> separate module in Hadoop repo. If maintained in separate repo, need to
> build this only when there are changes related to shaded dependencies.
>
>
> -Vinay
>
> On Sun, 22 Sep 2019, 10:11 pm Steve Loughran, <ste...@cloudera.com> wrote:
>
> >
> >
> > On Sun, Sep 22, 2019 at 3:22 PM Vinayakumar B <vinayakum...@apache.org>
> > wrote:
> >
> >>    Protobuf provides Wire compatibility between releases.. but not
> >> guarantees the source compatibility in generated sources. There will be
> a
> >> problem in compatibility if anyone uses generated protobuf message
> outside
> >> of Hadoop modules. Which ideally shouldn't be as generated sources are
> not
> >> public APIs.
> >>
> >>    There should not be any compatibility problems between releases in
> >> terms
> >> of communication provided both uses same syntax (proto2) of proto
> message.
> >> This I have verified by communication between protobuf 2.5.0 client with
> >> protobuf 3.7.1 server.
> >>
> >>    To avoid the downstream transitive dependency classpath problem, who
> >> might be using protobuf 2.5.0 classes, planning to shade the 3.7.1
> classes
> >> and its usages in all hadoop modules.. and keep 2.5.0 jar back in hadoop
> >> classpath.
> >>
> >> Hope I have answered your question.
> >>
> >> -Vinay
> >>
> >>
> > While I support the move and CP isolation, this is going to (finally)
> > force us to make shaded versions of all artifacts which we publish with
> the
> > intent of them being loaded on the classpath of other applications
> >
>

Reply via email to