I'm fine as long as we are committed to fixing the shading problems before
the release. Ideally I think we should fix the shading problems first and
then remove the hive-exec:core jar though (which is I said it's a bit
premature to do it now).
On Thu, Nov 18, 2021 at 8:28 AM Stamatis Zampetakis
w
Hello,
I don't see any risk committing this right now in master. It will only
affect the new Hive release when and if it ever goes out.
Till then we have plenty of time to fix shading problems and help other
projects migrate to the "recommended" way to use Hive.
Moreover, I don't know many projec
On 11/17/21 7:46 PM, Chao Sun wrote:
We have a working hive-exec jar
I'm not sure about this. The issue comes when the fat hive-exec jar shades
some jars but doesn't relocate them. In this case there is no way for the
downstream projects to resolve the conflict.
Exactly - I think those sho
> We have a working hive-exec jar
I'm not sure about this. The issue comes when the fat hive-exec jar shades
some jars but doesn't relocate them. In this case there is no way for the
downstream projects to resolve the conflict.
On the Spark side IIUC we had issues with Apache Commons as well as O
On 11/17/21 7:07 PM, Daniel Fritsi wrote:
For Oozie we've decided to use fat Jar downstream (Cloudera) as there we have
processes to ensure 3rd-party library versions are kept in sync.
Since we don't have such a process in Apache, there we'll continue to use the
core Jar.
It might be possibl
On 11/17/21 6:50 PM, Chao Sun wrote:
the idea is to fix the issues they bump into - because people who load
the jdbc driver may also see those issues.
I don’t get what you mean here, could you elaborate a bit more?
I suggest to work with the downstream projects people and smash out issues
For Oozie we've decided to use fat Jar downstream (Cloudera) as there we
have processes to ensure 3rd-party library versions are kept in sync.
Since we don't have such a process in Apache, there we'll continue to
use the core Jar.
Dan
On 2021. 11. 17. 18:50, Chao Sun wrote:
the idea is to f
> the idea is to fix the issues they bump into - because people who load
the jdbc driver may also see those issues.
I don’t get what you mean here, could you elaborate a bit more?
IMO it's a bit premature to do this without a working hive-exec jar for
downstream projects like Spark/Trino/Presto.
Hey all,
I wanted to get back to this - but had other things going on.
Chao> it is still being used today by some other popular projects
the idea is to fix the issues they bump into - because people who load the jdbc
driver may also see those issues.
Edward> [...] You all must like enjoy shadi
recommendation from the Hive team is to use the hive-exec.jar artifact.
You know about 10 years ago. I mentioned that oozie should just use
hive-service or hive jdbc. After a big fight where folks kept bringing up
concurrency bugs in hive-server-1 my prs were rejected (even though hive
server2 wou
I'm not sure whether it is a good idea to remove `hive-exec-core`
completely - it is still being used today by some other popular projects
including Spark and Trino/Presto. By sticking to `hive-exec-core` it gives
more flexibility to the other projects to shade & relocate those classes
according to
Hey
On 9/6/21 12:48 PM, Stamatis Zampetakis wrote:
Indeed this may lead to binary incompatibility problems as the one you
mentioned. If I understood correctly the problem you cite comes up if
library B in this case is not relocated. If Hive systematically relocates
shaded deps do you think there
Hi Dan,
Thanks for kicking off this discussion and taking the time to propose
solutions.
As you correctly mentioned the recommendation from the Hive team is to
always use the hive-exec.jar (dependency) and never rely on
hive-exec-core.jar.
Indeed this may lead to binary incompatibility problems
13 matches
Mail list logo
