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 <[email protected]> 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
