Hi,
Sorry for the long mail.
It has three basic parts: "URLs for Gradle PR", "Motivation/new features",
"build time comparison".
>> Urls for Gradle PR
I've started a PR for migrating Avatica build system from Maven to Gradle:
https://github.com/apache/calcite-avatica/pull/104
I've put a list of
Thanks everybody for helpful comments.
At this point I'm confident the change is good, so I'm inclined to just
commit it and cleanup glitches later if any.
I'm inclined to remove pom.xml files from Git control as well.
PS. There was Gradle-produced release candidate. You can find it under the
sub
Thanks for the effort Vladimir !
Best,
Danny Chan
在 2019年9月12日 +0800 PM8:38，Vladimir Sitnikov ，写道：
> Thanks everybody for helpful comments.
>
> At this point I'm confident the change is good, so I'm inclined to just
> commit it and cleanup glitches later if any.
> I'm inclined to remove pom.xml fi
The performance improvement with Gradle is appealing. I would like to give it a
try.
- Haisheng
--
发件人：Vladimir Sitnikov
日 期：2019年07月01日 21:11:41
收件人：Apache Calcite dev list
主 题：CALCITE-3158, Avatica: migrate build system to Gradle
Michael> I agree with Julian's point about adding maintenance
Michael> overhead.
Frankly speaking, it is (still) extremely hard for me to decipher Julian's
mail.
It is so dense that I can't really understand the meaning.
For instance:
Julian>Proof that the amount of knowledge required to maintai
Let me paraphrase.
You asked for proof. No proof is needed. It is self-evident.
Julian
> On Jul 2, 2019, at 9:01 AM, Vladimir Sitnikov
> wrote:
>
> Michael> I agree with Julian's point about adding maintenance
> Michael> overhead.
>
> Frankly speaking, it is (still) extremely hard for me t
> As you say, you "haven't encountered that".
My maven does work the same as yours in that I do have to take the
steps you outlined. I just haven't found it to be burdensome.
> I know of no Java-based build system. Why do you ask for that?
One of the concerns was adding another language. If this
Michael>One of the concerns was adding another language
It is not adding, but it is replacing a language.
I replace "pom logic written in XML" with "Gradle logic written in Kotlin".
Then it would probably replace /bin/bash-driven logic with the same
"Gradle+Kotlin",
which would remove yet another
I will support changes, such as you describe, that add a language and remove
another.
I am wary of changes that add a new language (or framework, for that matter) to
the mix. Hence my pushback against your use of .kts files.
We can’t entirely remove Maven and pom.xml files from the process. pom
Julian>Do you propose to remove pom.xml files from git
Of course I do.
I just thought "migrate Maven to Gradle" to mean "we fully replace Maven
with Gradle",
not like "we add Gradle build scripts and support two build systems at the
same time".
Julian>generate them upon release
Gradle can genera
Here's an update: Gradle-based build seems to be in a quite a good shape.
Just in case: it builds source artifacts (in zip and tgz formats), it
assembles licenses, it runs tests.
The missing bit is /docker/pom.xml -- I have no idea what it does.
Any feedback?
Vladimir
Before we accept this, I would like to make sure that the source
artifacts are identical (in terms of name, contents, internal
directory structure) to the artifacts we produce today, and the same
goes for the contents of the JAR files (manifests,
META-INF/service/java.sql.Driver files) and generate
Hi Vladimir,
First of all thanks a lot for the great work so far!
I never used Gradle before but I am rather convinced with all the positive
points that you raised through the various discussion so far.
Although Maven seems to be the most popular build tool, I followed various
discussions highlig
Thanks Vladimir! Sorry for the delayed response. I haven't looked over
the artifacts myself in detail, but the diffs you mention don't raise
any red flags for me. I'm not sure what you mean by the "docker
module" though. As far as cleaning up the artifacts, I assume we
should implement a similar po
Vladimir Sitnikov created CALCITE-3158:
--
Summary: Avatica: migrate build system to Gradle
Key: CALCITE-3158
URL: https://issues.apache.org/jira/browse/CALCITE-3158
Project: Calcite
Issue
Haisheng
--
发件人：Vladimir Sitnikov
日 期：2019年07月03日 00:01:31
收件人：Apache Calcite dev list
主 题：Re: CALCITE-3158, Avatica: migrate build system to Gradle
Michael> I agree with Julian's point about adding maintenance
Michael> overhead.
Frankly speaking, it is (still) extre
16 matches
Mail list logo
