PR has been merged.
Thanks everyone for discussions.
-Vinay
On Thu, Jan 9, 2020 at 4:47 PM Ayush Saxena wrote:
> Hi All,
> FYI :
> We will be going ahead with the present approach, will merge by tomorrow
> EOD. Considering no one has objections.
> Thanx Everyone!!!
>
> -Ayush
>
> > On
Hi All,
FYI :
We will be going ahead with the present approach, will merge by tomorrow EOD.
Considering no one has objections.
Thanx Everyone!!!
-Ayush
> On 07-Jan-2020, at 9:22 PM, Brahma Reddy Battula wrote:
>
> Hi Sree vaddi,Owen,stack,Duo Zhang,
>
> We can move forward based on your
Hi Sree vaddi,Owen,stack,Duo Zhang,
We can move forward based on your comments, just waiting for your
reply.Hope all of your comments answered..(unification we can think
parallel thread as Vinay mentioned).
On Mon, 6 Jan 2020 at 6:21 PM, Vinayakumar B
wrote:
> Hi Sree,
>
> >
Hi Sree,
> apache/hadoop-thirdparty, How would it fit into ASF ? As an Incubating
Project ? Or as a TLP ?
> Or as a new project definition ?
As already mentioned by Ayush, this will be a subproject of Hadoop.
Releases will be voted by Hadoop PMC as per ASF process.
> The effort to streamline
Hey Sree
> apache/hadoop-thirdparty, How would it fit into ASF ? As an Incubating
> Project ? Or as a TLP ?
> Or as a new project definition ?
>
A sub project of Apache Hadoop, having its own independent release cycles.
May be you can put this into the same column as ozone or as
submarine(couple
I just gone through previous discussions from jira (HADOOP-13363) and this
thread,As stack and Duo Zhang mentioned ,this artifact(instead of
thirdparty we can give shaded??) will be voted by PMC like below, won’t it
be fair??
apache/hadoop-thirdparty, How would it fit into ASF ? As an Incubating Project
? Or as a TLP ?
Or as a new project definition ?
The effort to streamline and put in an accepted standard for the dependencies
that require shading,seems beyond the siloed efforts of hadoop, hbase, etc
I
Hi,
Sorry for the late reply,.
>>> To be exact, how can we better use the thirdparty repo? Looking at
HBase as an example, it looks like everything that are known to break a lot
after an update get shaded into the hbase-thirdparty artifact: guava,
netty, ... etc.
Is it the purpose to isolate these
Hi I am late to this but I am keen to understand more.
To be exact, how can we better use the thirdparty repo? Looking at HBase as
an example, it looks like everything that are known to break a lot after an
update get shaded into the hbase-thirdparty artifact: guava, netty, ... etc.
Is it the
Hi All,
I have updated the PR as per @Owen O'Malley
's suggestions.
i. Renamed the module to 'hadoop-shaded-protobuf37'
ii. Kept the shaded package to 'o.a.h.thirdparty.protobuf37'
Please review!!
Thanks,
-Vinay
On Sat, Sep 28, 2019 at 10:29 AM 张铎(Duo Zhang)
wrote:
> For HBase we
For HBase we have a separated repo for hbase-thirdparty
https://github.com/apache/hbase-thirdparty
We will publish the artifacts to nexus so we do not need to include
binaries in our git repo, just add a dependency in the pom.
Please find replies inline.
-Vinay
On Fri, Sep 27, 2019 at 10:21 PM Owen O'Malley
wrote:
> I'm very unhappy with this direction. In particular, I don't think git is
> a good place for distribution of binary artifacts. Furthermore, the PMC
> shouldn't be releasing anything without a release
I'm very unhappy with this direction. In particular, I don't think git is a
good place for distribution of binary artifacts. Furthermore, the PMC
shouldn't be releasing anything without a release vote.
I'd propose that we make a third party module that contains the *source* of
the pom files to
Hi All,
I wanted to discuss about the separate repo for thirdparty dependencies
which we need to shaded and include in Hadoop component's jars.
Apologies for the big text ahead, but this needs clear explanation!!
Right now most needed such dependency is protobuf. Protobuf dependency
14 matches
Mail list logo
