Can you send an email to the cloudera maintenance team to explain this 
situation, and hope they will submit this to the central warehouse of maven




------------------ 原始邮件 ------------------
发件人:                                                                            
                                            "dev"                               
                                                     <lingm...@apache.org&gt;;
发送时间:&nbsp;2020年10月28日(星期三) 下午4:48
收件人:&nbsp;"dev"<dev@doris.apache.org&gt;;

主题:&nbsp;Re: [Proposal] Put some dependencies in our maintenance repo



Hi Duo,

I found another dependency package with similar functions, let's see if I
can replace it.

Regarding the question of Calcite, we have previously investigated Calcite
for Doris to optimize the query framework.
After the evaluation, it is found that the access cost may be similar to
the reconstruction of the entire query framework , so it is a long-term
work in the future.

Ling Miao


张铎(Duo Zhang) <palomino...@gmail.com&gt; 于2020年10月27日周二 下午9:53写道:

&gt; Could be a long term solution? Is there any other reason which prevents us
&gt; using Calcite?
&gt;
&gt; ling miao <lingm...@apache.org&gt; 于2020年10月27日周二 下午8:02写道:
&gt;
&gt; &gt; Hi Duo,
&gt; &gt;
&gt; &gt; Using calcite directly will definitely not work, which means that the
&gt; query
&gt; &gt; analysis + planning are rewritten.
&gt; &gt; But&nbsp; maybe we can use other parser tools to replace it, or 
something
&gt; &gt; similar.
&gt; &gt; However, it is estimated that the amount of change for this solution.
&gt; &gt; ...(。•ˇ‸ˇ•。)
&gt; &gt; ...
&gt; &gt;
&gt; &gt; Ling Miao
&gt; &gt;
&gt; &gt; 张铎(Duo Zhang) <palomino...@gmail.com&gt; 于2020年10月27日周二 下午6:34写道:
&gt; &gt;
&gt; &gt; &gt; I think this is used to generate the SQL parser? Is it possible 
to use
&gt; &gt; &gt; Calcite directly?
&gt; &gt; &gt;
&gt; &gt; &gt; ling miao <lingm...@apache.org&gt; 于2020年10月26日周一 下午7:38写道:
&gt; &gt; &gt;
&gt; &gt; &gt; &gt; Hi,
&gt; &gt; &gt; &gt;
&gt; &gt; &gt; &gt; Currently, some fe dependencies that we rely on are not in 
the maven
&gt; &gt; &gt; repo.
&gt; &gt; &gt; &gt; For example, cup-maven-plugin and java-cup are located at 
the
&gt; Cloudera
&gt; &gt; &gt; &gt; 3rd-P.
&gt; &gt; &gt; &gt; This will lead to the risk that our code will not be 
compiled when
&gt; the
&gt; &gt; &gt; &gt; third-party repo changes.
&gt; &gt; &gt; &gt;
&gt; &gt; &gt; &gt; I have also tried whether it is possible to replace these
&gt; dependencies
&gt; &gt; &gt; &gt; with other packages or versions, but unfortunately the only 
thing we
&gt; &gt; can
&gt; &gt; &gt; &gt; use at the moment is this.
&gt; &gt; &gt; &gt;
&gt; &gt; &gt; &gt; So I propose whether we can maintain these jar packages in 
our own
&gt; repo
&gt; &gt; &gt; to
&gt; &gt; &gt; &gt; ensure that they can be found every time we compile?
&gt; &gt; &gt; &gt;
&gt; &gt; &gt; &gt; Or do you have any better solutions?
&gt; &gt; &gt; &gt;
&gt; &gt; &gt; &gt; Ling Miao
&gt; &gt; &gt; &gt;
&gt; &gt; &gt;
&gt; &gt;
&gt;

Reply via email to