You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ratis.apache.org by Enis Söztutar <en...@gmail.com> on 2017/04/01 00:38:33 UTC

Do shading as a last step?

Hugo and I were discussing a case were the shading should happen at the
last step, rather than what we do today.

I think there are 3 possible strategies of shading that one can do:
 (1) pre-shade some of your dependencies, so that your other dependencies
can work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can
work.
 (2) pre-shade some of your dependencies' transitive dependencies so that
you depend on already-shaded artifacts. This will be like having maven
artifacts of shaded-hadoop so that hadoop itself does not bring in any more
dependency. If hadoop has shaded artifacts, or we do shading of hadoop's
dependencies in another repository, we won't need to pre-shade PB, etc.
 (3) post-shade. This means that in the code itself we do not depend on
shaded packages anymore, but do the shading as a different module so that
we publish shaded artifacts. This allows the downstreamers to be able to
consume ratis, while allowing ratis source code to be saner.

Obviously for doing (3), we need to kick out ratis-hadoop module to the
hadoop project. Thinking about it, I think ratis-hadoop does not belong in
Ratis itself anyway. What do you guys think about moving the code over to
Hadoop, and getting rid of the hadoop dependency to end this shading
madness?

Enis

Re: Do shading as a last step?

Posted by Enis Söztutar <en...@gmail.com>.
Thanks Nicholas,

I've created https://issues.apache.org/jira/browse/RATIS-64 for this. Let's
continue there.

Enis

On Fri, Mar 31, 2017 at 8:03 PM, Tsz Wo Sze <sz...@gmail.com> wrote:

> I am open to change the shading procedure but I like to understand the
> motivation.  First of all, what is the problem we try to solve?  Is it
> to avoid the imports from org.apache.ratis.shaded packages in our
> source code?
>
> #3 sounds like a good idea.  But why we need to kick out ratis-hadoop?
>  I mean why it can't be post-shaded?
>
> BTW, let's create a JIRA for discussion.  It usually is easier to follow.
>
> Nicholas
>
> On Sat, Apr 1, 2017 at 8:38 AM, Enis Söztutar <en...@gmail.com> wrote:
> > Hugo and I were discussing a case were the shading should happen at the
> > last step, rather than what we do today.
> >
> > I think there are 3 possible strategies of shading that one can do:
> >  (1) pre-shade some of your dependencies, so that your other dependencies
> > can work. This what we do today, we shade PB+ GRPC, etc so that Hadoop
> can
> > work.
> >  (2) pre-shade some of your dependencies' transitive dependencies so that
> > you depend on already-shaded artifacts. This will be like having maven
> > artifacts of shaded-hadoop so that hadoop itself does not bring in any
> more
> > dependency. If hadoop has shaded artifacts, or we do shading of hadoop's
> > dependencies in another repository, we won't need to pre-shade PB, etc.
> >  (3) post-shade. This means that in the code itself we do not depend on
> > shaded packages anymore, but do the shading as a different module so that
> > we publish shaded artifacts. This allows the downstreamers to be able to
> > consume ratis, while allowing ratis source code to be saner.
> >
> > Obviously for doing (3), we need to kick out ratis-hadoop module to the
> > hadoop project. Thinking about it, I think ratis-hadoop does not belong
> in
> > Ratis itself anyway. What do you guys think about moving the code over to
> > Hadoop, and getting rid of the hadoop dependency to end this shading
> > madness?
> >
> > Enis
>

Re: Do shading as a last step?

Posted by Tsz Wo Sze <sz...@gmail.com>.
I am open to change the shading procedure but I like to understand the
motivation.  First of all, what is the problem we try to solve?  Is it
to avoid the imports from org.apache.ratis.shaded packages in our
source code?

#3 sounds like a good idea.  But why we need to kick out ratis-hadoop?
 I mean why it can't be post-shaded?

BTW, let's create a JIRA for discussion.  It usually is easier to follow.

Nicholas

On Sat, Apr 1, 2017 at 8:38 AM, Enis Söztutar <en...@gmail.com> wrote:
> Hugo and I were discussing a case were the shading should happen at the
> last step, rather than what we do today.
>
> I think there are 3 possible strategies of shading that one can do:
>  (1) pre-shade some of your dependencies, so that your other dependencies
> can work. This what we do today, we shade PB+ GRPC, etc so that Hadoop can
> work.
>  (2) pre-shade some of your dependencies' transitive dependencies so that
> you depend on already-shaded artifacts. This will be like having maven
> artifacts of shaded-hadoop so that hadoop itself does not bring in any more
> dependency. If hadoop has shaded artifacts, or we do shading of hadoop's
> dependencies in another repository, we won't need to pre-shade PB, etc.
>  (3) post-shade. This means that in the code itself we do not depend on
> shaded packages anymore, but do the shading as a different module so that
> we publish shaded artifacts. This allows the downstreamers to be able to
> consume ratis, while allowing ratis source code to be saner.
>
> Obviously for doing (3), we need to kick out ratis-hadoop module to the
> hadoop project. Thinking about it, I think ratis-hadoop does not belong in
> Ratis itself anyway. What do you guys think about moving the code over to
> Hadoop, and getting rid of the hadoop dependency to end this shading
> madness?
>
> Enis