CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Hi,

I wonder what you think of migrating Maven to Gradle.

I think one of the main points for having Gradle would be:
1) Eliminate "mvn install" for local testing. Calcite consists of
multiple Maven modules, however Maven always uses jars from the local
repository.
That is if you modify a file in "core", then you can't just invoke mvn
test from "cassandra". You have to "mvn install" "core" first.
There are workarounds (e.g. "mvn install" all the modules every time)

In Gradle, "multi-module" build feels more like "always composite
module". In other words, even if you invoke "build" task from within
"core" module, Gradle would find all the modules in current project,
it would compute all the dependencies and build accordingly.
In my opinion it makes a big difference.

There's a support for cross-project incremental builds as well. I
haven't used that, however the idea there is that one can have
"calcite" and "drill" as different Gradle projects, however one can
modify a file in Calcite and invoke "build" from a Drill folder. It
would build Calcite first.

2) Maven task/plugins often fail to declare inputs/outputs. This
causes issues like MSHARED-394: Avoid rewrite of destination in
DefaultMavenFileFilter#filterFile when producing the same contents.
Gradle embrases tasks authors to declare inputs outputs (e.g. files or
just property values) and it enables the build system to track stale
tasks.

Gradle supports "buildSrc" folder which can contain code that is
available to the buildfiles of a current project. It enables to
express build logic in a much more sound programming language than
XML.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Update: I think Gradle-based build for JMeter is 99.42% complete, and I'm
quite happy with that (the link is still
https://github.com/apache/jmeter/pull/448 )
I have commands like "./gradlew prepareVote" that builds artifacts, stages
them to dist.apache.org / repository.apache.org, builds documentation
preview, publishes it along with RAT report to a Git repository (e.g.
GitHub pages preview), and prepares "[VOTE]" email.
Note: I have stub implementations for Nexus, SVN (
https://github.com/vlsi/asflike-release-environment ), so everybody can try
that out with zero risks of updating apache.org servers.

I have "./gradlew runGui" that builds artifacts and launches the app
automatically (== which would be very handy for our ./sqlline since we can
delegate classpath build and cache to Gradle)

If you are feeling lucky/curious, please check out apache/jmeter/pull/448
and try loading the project in IDE / executing some commands (there's a
list in PR description)

The only "sad" point I found is Kotlin-based build scripts take a bit to
compile (e.g. it might take 10-20 seconds to compile "10 build scripts"
after modification of the core build file), however I think it is not a
problem since we don't modify build files often. Subsequent executions are
super-fast.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Francis Chuang]

This is a good idea. For avatica-go, I've implemented something similar 
using a bash script and docker-compose [1] [2]. For avatica, I've also 
implemented a bash script and docker-compose for making releases [3] 
[4]. Hopefully, this is something we can do for avatica as well, then we 
can remove the bash script and use docker-compose to wrap around Gradle 
(for those who want to run the release build process in docker).


Currently I've the following steps automated (see avatica's HOWTO for 
more details [5]):

1. Build release.
2. Upload release to dev svn respoitory and generate vote email.
3. Tag final release and push and then move rc release to the release 
svn repository.


[1] https://github.com/apache/calcite-avatica-go/blob/master/docker.sh
[2] 
https://github.com/apache/calcite-avatica-go/blob/master/docker-compose.yml

[3] https://github.com/apache/calcite-avatica/blob/master/docker.sh
[4] https://github.com/apache/calcite-avatica/blob/master/docker-compose.yml
[5] 
https://calcite.apache.org/avatica/docs/howto.html#making-a-release-for-calcite-committers


On 30/05/2019 8:09 pm, Vladimir Sitnikov wrote:

Update: I think Gradle-based build for JMeter is 99.42% complete, and I'm
quite happy with that (the link is still
https://github.com/apache/jmeter/pull/448 )
I have commands like "./gradlew prepareVote" that builds artifacts, stages
them to dist.apache.org / repository.apache.org, builds documentation
preview, publishes it along with RAT report to a Git repository (e.g.
GitHub pages preview), and prepares "[VOTE]" email.
Note: I have stub implementations for Nexus, SVN (
https://github.com/vlsi/asflike-release-environment ), so everybody can try
that out with zero risks of updating apache.org servers.

I have "./gradlew runGui" that builds artifacts and launches the app
automatically (== which would be very handy for our ./sqlline since we can
delegate classpath build and cache to Gradle)

If you are feeling lucky/curious, please check out apache/jmeter/pull/448
and try loading the project in IDE / executing some commands (there's a
list in PR description)

The only "sad" point I found is Kotlin-based build scripts take a bit to
compile (e.g. it might take 10-20 seconds to compile "10 build scripts"
after modification of the core build file), however I think it is not a
problem since we don't modify build files often. Subsequent executions are
super-fast.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Francis>using a bash script

Oh, that is a great amount of work.

I'm not sure if release procedures for Avatica and Calcite differ much,
however it might be a good idea to migrate Avatica first.
I guess the number of changes coming to Avatica is much less, and we can
polish Gradle / release there.
What do you think?

By the way, I like the way Gradle enables to release *without* committing
changes.
In other words:

1)
$ gw build
...
> Configure project :
Building JMeter 5.2.0-2ba449c-SNAPSHOT

2)
$ gw -Pnightly=false build
...
> Configure project :
Building JMeter 5.2.0-SNAPSHOT

3)
$ gw -Prelease build
...
> Configure project :
Building JMeter 5.2.0

Of course the version has to be updated after the release, however
a) There's nothing to rollback in case of a failure which is supercool
b) Everybody else can build exactly the same commit in "release mode" and
verify if the produced SHAs match the ones published by a release manager.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Francis Chuang]

Definitely +1 for trying it out in Avatica first. Avatica's release 
procedure looks quite similar to Calcite's with Avatica's being slightly 
simpler.


On 30/05/2019 10:34 pm, Vladimir Sitnikov wrote:

Francis>using a bash script

Oh, that is a great amount of work.

I'm not sure if release procedures for Avatica and Calcite differ much,
however it might be a good idea to migrate Avatica first.
I guess the number of changes coming to Avatica is much less, and we can
polish Gradle / release there.
What do you think?

By the way, I like the way Gradle enables to release *without* committing
changes.
In other words:

1)
$ gw build
...

Configure project :

Building JMeter 5.2.0-2ba449c-SNAPSHOT

2)
$ gw -Pnightly=false build
...

Configure project :

Building JMeter 5.2.0-SNAPSHOT

3)
$ gw -Prelease build
...

Configure project :

Building JMeter 5.2.0

Of course the version has to be updated after the release, however
a) There's nothing to rollback in case of a failure which is supercool
b) Everybody else can build exactly the same commit in "release mode" and
verify if the produced SHAs match the ones published by a release manager.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

As you might know, Avatica is already migrated to Gradle.

On top of that, Calcite is almost there as well:
https://github.com/apache/calcite/pull/1571

The missing bit is probably the notion of tests "fast/slow/etc/etc".
Unfortunately, there are tests that assert on folder layout like
"target/test-classes".
I'm going to ignore those tests for now, and fix them as pom.xml files are
removed.

I'm going to configure Gradle to use JUnit5 engine to run the tests.

In the meantime, everybody's welcome to preview Gradle build.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Stamatis Zampetakis]

Hi Vladimir,

Thanks for working on this.

I have a quick question regarding fast/slow tests.

Currently we have two ways of running/skipping a slow test:
* using the SlowTests annotation and using JUnit categories;
* using the system property calcite.test.slow.

I was planning (WIP in [1]) to unify the two by annotating all slow tests
with the appropriate annotation.
Does this make sense considering the ongoing work of moving to Gradle and
JUnit5?
Are you planning to keep/use these kind of annotations?

Best,
Stamatis

[1] https://github.com/apache/calcite/pull/1375




On Mon, Nov 11, 2019 at 11:30 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> As you might know, Avatica is already migrated to Gradle.
>
> On top of that, Calcite is almost there as well:
> https://github.com/apache/calcite/pull/1571
>
> The missing bit is probably the notion of tests "fast/slow/etc/etc".
> Unfortunately, there are tests that assert on folder layout like
> "target/test-classes".
> I'm going to ignore those tests for now, and fix them as pom.xml files are
> removed.
>
> I'm going to configure Gradle to use JUnit5 engine to run the tests.
>
> In the meantime, everybody's welcome to preview Gradle build.
>
> Vladimir
>

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

>Currently we have two ways of running/skipping a slow test

You wanted to say "at least two", did you?
There are properties like calcite.test.druid which target a single test
class.

>Does this make sense considering the ongoing work of moving to Gradle and
JUnit5?

The current Gradle-JUnit5 build uses **both** skipping options at the same
time, because I want minimal changes to the source code.
I'm not sure what is the better way, but I do like how JUnit5 enables to
have short tags and tag expressions to filter tests.

We could even tag tests with "@ExpectedDuration" and provide an option like
"run all tests that typically fit in 5sec"

>to unify the two by annotating all slow tests with the appropriate
annotation

I would suggest doing that after Gradle migration. WDYT?

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

The Gradle build scripts are ready (
https://github.com/apache/calcite/pull/1571 )
There might be minor issues like "a resource file missing in one of the
jars",
however, I expect there will be no more major changes.


Unfortunately, there are changes that prevent building with both Maven and
Gradle from the same commit.
For instance, Maven uses
"core/src/main/resources/version/org-apache-calcite-jdbc.properties" for
figuring out driver version.
And Gradle build just generates CalciteDriverVersion.java
I don't want to over-engineer pom.xml files, so I did not try to make
pom.xml files buildable.
However, pom.xml files will be removed right after Gradle script is merged.

The other change is Druid migrated from JUnit4 to JUnit5 (to enable the use
of Assumptions).

I'm inclined to commit the change, so please feel free to review it.

In case you missed, you can start playing with the build with the commands
that are listed in the commit message:
https://github.com/apache/calcite/pull/1571/commits/4bbf1cdeac6e09959e027eaa482a67937228bf9d
"./gradlew tasks" could be a good start.

The file movements/edits are minimal, so I hope it won't affect pending PRs.


Note, as I said earlier, having both Avatica and Calcite in Gradle enables
us to load both projects to the IDE at the same time.
In the same way, one can test who Avatica fix impacts Calcite with a single
command line. No changes to pom.xml needed!!!

The procedure is to clone calcite-avatica and calcite side by side, and use
-PlocalAvatica property.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Stamatis Zampetakis]

I am totally OK for doing the unification after the Gradle migration.

Other than that, I had a quick look and left some comments directly in the
PR. I will try to test it when I find some time.

On Thu, Nov 14, 2019 at 10:27 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> The Gradle build scripts are ready (
> https://github.com/apache/calcite/pull/1571 )
> There might be minor issues like "a resource file missing in one of the
> jars",
> however, I expect there will be no more major changes.
>
>
> Unfortunately, there are changes that prevent building with both Maven and
> Gradle from the same commit.
> For instance, Maven uses
> "core/src/main/resources/version/org-apache-calcite-jdbc.properties" for
> figuring out driver version.
> And Gradle build just generates CalciteDriverVersion.java
> I don't want to over-engineer pom.xml files, so I did not try to make
> pom.xml files buildable.
> However, pom.xml files will be removed right after Gradle script is merged.
>
> The other change is Druid migrated from JUnit4 to JUnit5 (to enable the use
> of Assumptions).
>
> I'm inclined to commit the change, so please feel free to review it.
>
> In case you missed, you can start playing with the build with the commands
> that are listed in the commit message:
>
> https://github.com/apache/calcite/pull/1571/commits/4bbf1cdeac6e09959e027eaa482a67937228bf9d
> "./gradlew tasks" could be a good start.
>
> The file movements/edits are minimal, so I hope it won't affect pending
> PRs.
>
>
> Note, as I said earlier, having both Avatica and Calcite in Gradle enables
> us to load both projects to the IDE at the same time.
> In the same way, one can test who Avatica fix impacts Calcite with a single
> command line. No changes to pom.xml needed!!!
>
> The procedure is to clone calcite-avatica and calcite side by side, and use
> -PlocalAvatica property.
>
> Vladimir
>

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Update: the build script is ready, the documentation is updated, CI passes
(including a new CI check with "build Avatica from master => test with
Calcite".

The only missing bit is removal of pom.xml files.
Note: both Maven and Gradle scripts work at the same time from the same
commit, however, the intention is to remove pom.xml right with migration to
Gradle.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Thank you, everybody, for the review.

I've merged the change, so the build is Gradle-based now. I hope I did not
break too many workflows with that change.

Just in case, the new build steps are on the website (
https://calcite.apache.org/docs/howto.html#running-tests ).
$ ./gradlew assemble # build the artifacts
$ ./gradlew build -x test # build the artifacts, verify code style, skip
tests
$ ./gradlew check # verify code style, execute tests
$ ./gradlew test # execute tests
$ ./gradlew style # update code formatting (for auto-correctable cases) and
verify style
$ ./gradlew spotlessCheck checkstyleAll # report code style violations

IDEs might remember that "the project was Maven-based", so the easiest way
to migrate might be to remove project files and import
Gradle build.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Danny Chan]

Thanks for the great work Vladimir ~

I have tried the build with new gradle facilities and it is much faster !

Just have one question, how do I run the tests with diffRepository in the IDEA 
? Such as RelOptRulesTest, I run it in IDEA but it could not find the xml 
resource file.

Best,
Danny Chan
在 2019年11月19日 +0800 PM6:25，Vladimir Sitnikov ，写道：
> Thank you, everybody, for the review.
>
> I've merged the change, so the build is Gradle-based now. I hope I did not
> break too many workflows with that change.
>
> Just in case, the new build steps are on the website (
> https://calcite.apache.org/docs/howto.html#running-tests ).
> $ ./gradlew assemble # build the artifacts
> $ ./gradlew build -x test # build the artifacts, verify code style, skip
> tests
> $ ./gradlew check # verify code style, execute tests
> $ ./gradlew test # execute tests
> $ ./gradlew style # update code formatting (for auto-correctable cases) and
> verify style
> $ ./gradlew spotlessCheck checkstyleAll # report code style violations
>
> IDEs might remember that "the project was Maven-based", so the easiest way
> to migrate might be to remove project files and import
> Gradle build.
>
> Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

>I have tried the build with new gradle facilities and it is much faster !

Thank you.
I hope you would like that "wrong import order", "whitespace at the end of
the file", "wrong copyright", etc issues
are now reported in a diff-style, and they are auto-fixable.

>Such as RelOptRulesTest, I run it in IDEA but it could not find the xml
resource file

Oh,  that's unfortunate.
Are you using your old project or have you re-created the project from
scratch?

It cannot reproduce the issue though.

Can you provide the stacktrace?
What's your IDEA version?

For instance:
git clone --depth 100 https://github.com/apache/calcite.git calcite-t1
Open calcite-t1/build.gradle.kts in IDEA. Select "open as project".

Navigate to RelOptRulesTest, run it. It runs for me.
Well, by default it uses Gradle to execute the tests, so it is expected to
work.
It is the default under "Build / Build Tools / Gradle -> Run tests using"
option.

If I select "Run tests using" == "choose per test", right-click the test
class and run it with IDEA runner, then it executes just fine (with IDEA
runner).

If I select "build and run with == IDEA", re-execute the test, then IDEA
creates out/... folder with classes, but the test still works.

In other words, all execution modes in IDEA work for me. I'm using IDEA
2019.3 EAP by the way.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Danny Chan]

Thanks, it is because I open an existing mvn project, re-open a new one
works for me.

Thanks so much again for the great work, I’m still learning gradle, it
broadly looks pretty good!

Vladimir Sitnikov 于2019年11月19日 周二下午9:23写道：

> >I have tried the build with new gradle facilities and it is much faster !
>
> Thank you.
> I hope you would like that "wrong import order", "whitespace at the end of
> the file", "wrong copyright", etc issues
> are now reported in a diff-style, and they are auto-fixable.
>
> >Such as RelOptRulesTest, I run it in IDEA but it could not find the xml
> resource file
>
> Oh,  that's unfortunate.
> Are you using your old project or have you re-created the project from
> scratch?
>
> It cannot reproduce the issue though.
>
> Can you provide the stacktrace?
> What's your IDEA version?
>
> For instance:
> git clone --depth 100 https://github.com/apache/calcite.git calcite-t1
> Open calcite-t1/build.gradle.kts in IDEA. Select "open as project".
>
> Navigate to RelOptRulesTest, run it. It runs for me.
> Well, by default it uses Gradle to execute the tests, so it is expected to
> work.
> It is the default under "Build / Build Tools / Gradle -> Run tests using"
> option.
>
> If I select "Run tests using" == "choose per test", right-click the test
> class and run it with IDEA runner, then it executes just fine (with IDEA
> runner).
>
> If I select "build and run with == IDEA", re-execute the test, then IDEA
> creates out/... folder with classes, but the test still works.
>
> In other words, all execution modes in IDEA work for me. I'm using IDEA
> 2019.3 EAP by the way.
>
> Vladimir
>

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Rui Wang]

I tested the gradle build but found a reproducible issue:

1. clone the master
2. change a line of code to a wrong indent
3. run ./gradlew style

I have been observing that at this moment, gradle will report a style check
failure but then is stuck and cannot exit without a ctrl-c (tried wait >20m
and not seeing command finishes by itself.)


-Rui

On Tue, Nov 19, 2019 at 5:43 AM Danny Chan  wrote:

> Thanks, it is because I open an existing mvn project, re-open a new one
> works for me.
>
> Thanks so much again for the great work, I’m still learning gradle, it
> broadly looks pretty good!
>
> Vladimir Sitnikov 于2019年11月19日 周二下午9:23写道：
>
> > >I have tried the build with new gradle facilities and it is much faster
> !
> >
> > Thank you.
> > I hope you would like that "wrong import order", "whitespace at the end
> of
> > the file", "wrong copyright", etc issues
> > are now reported in a diff-style, and they are auto-fixable.
> >
> > >Such as RelOptRulesTest, I run it in IDEA but it could not find the xml
> > resource file
> >
> > Oh,  that's unfortunate.
> > Are you using your old project or have you re-created the project from
> > scratch?
> >
> > It cannot reproduce the issue though.
> >
> > Can you provide the stacktrace?
> > What's your IDEA version?
> >
> > For instance:
> > git clone --depth 100 https://github.com/apache/calcite.git calcite-t1
> > Open calcite-t1/build.gradle.kts in IDEA. Select "open as project".
> >
> > Navigate to RelOptRulesTest, run it. It runs for me.
> > Well, by default it uses Gradle to execute the tests, so it is expected
> to
> > work.
> > It is the default under "Build / Build Tools / Gradle -> Run tests using"
> > option.
> >
> > If I select "Run tests using" == "choose per test", right-click the test
> > class and run it with IDEA runner, then it executes just fine (with IDEA
> > runner).
> >
> > If I select "build and run with == IDEA", re-execute the test, then IDEA
> > creates out/... folder with classes, but the test still works.
> >
> > In other words, all execution modes in IDEA work for me. I'm using IDEA
> > 2019.3 EAP by the way.
> >
> > Vladimir
> >
>

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Xiening Dai]

First want to thank you for woking on this. I try it today, and overall it 
looks great.

I also notice this output at the end, is this a known issue?

Deprecated Gradle features were used in this build, making it incompatible with 
Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See 
https://docs.gradle.org/6.0.1/userguide/command_line_interface.html#sec:command_line_warnings

Also is there an easy way to specify number of threads for build and test run?


> On Nov 19, 2019, at 5:43 AM, Danny Chan  wrote:
> 
> Thanks, it is because I open an existing mvn project, re-open a new one
> works for me.
> 
> Thanks so much again for the great work, I’m still learning gradle, it
> broadly looks pretty good!
> 
> Vladimir Sitnikov 于2019年11月19日 周二下午9:23写道：
> 
>>> I have tried the build with new gradle facilities and it is much faster !
>> 
>> Thank you.
>> I hope you would like that "wrong import order", "whitespace at the end of
>> the file", "wrong copyright", etc issues
>> are now reported in a diff-style, and they are auto-fixable.
>> 
>>> Such as RelOptRulesTest, I run it in IDEA but it could not find the xml
>> resource file
>> 
>> Oh,  that's unfortunate.
>> Are you using your old project or have you re-created the project from
>> scratch?
>> 
>> It cannot reproduce the issue though.
>> 
>> Can you provide the stacktrace?
>> What's your IDEA version?
>> 
>> For instance:
>> git clone --depth 100 https://github.com/apache/calcite.git calcite-t1
>> Open calcite-t1/build.gradle.kts in IDEA. Select "open as project".
>> 
>> Navigate to RelOptRulesTest, run it. It runs for me.
>> Well, by default it uses Gradle to execute the tests, so it is expected to
>> work.
>> It is the default under "Build / Build Tools / Gradle -> Run tests using"
>> option.
>> 
>> If I select "Run tests using" == "choose per test", right-click the test
>> class and run it with IDEA runner, then it executes just fine (with IDEA
>> runner).
>> 
>> If I select "build and run with == IDEA", re-execute the test, then IDEA
>> creates out/... folder with classes, but the test still works.
>> 
>> In other words, all execution modes in IDEA work for me. I'm using IDEA
>> 2019.3 EAP by the way.
>> 
>> Vladimir
>> 

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Xiening Dai]

Also I am getting a build break on appveyor. It seems relate to puppycrawl 
check style. Any idea?

https://ci.appveyor.com/project/ApacheSoftwareFoundation/calcite/builds/28981761/job/hd165mjr65gj0xal
 

 

> On Nov 19, 2019, at 4:07 PM, Xiening Dai  wrote:
> 
> First want to thank you for woking on this. I try it today, and overall it 
> looks great.
> 
> I also notice this output at the end, is this a known issue?
> 
> Deprecated Gradle features were used in this build, making it incompatible 
> with Gradle 7.0.
> Use '--warning-mode all' to show the individual deprecation warnings.
> See 
> https://docs.gradle.org/6.0.1/userguide/command_line_interface.html#sec:command_line_warnings
> 
> Also is there an easy way to specify number of threads for build and test run?
> 
> 
>> On Nov 19, 2019, at 5:43 AM, Danny Chan  wrote:
>> 
>> Thanks, it is because I open an existing mvn project, re-open a new one
>> works for me.
>> 
>> Thanks so much again for the great work, I’m still learning gradle, it
>> broadly looks pretty good!
>> 
>> Vladimir Sitnikov 于2019年11月19日 周二下午9:23写道：
>> 
 I have tried the build with new gradle facilities and it is much faster !
>>> 
>>> Thank you.
>>> I hope you would like that "wrong import order", "whitespace at the end of
>>> the file", "wrong copyright", etc issues
>>> are now reported in a diff-style, and they are auto-fixable.
>>> 
 Such as RelOptRulesTest, I run it in IDEA but it could not find the xml
>>> resource file
>>> 
>>> Oh,  that's unfortunate.
>>> Are you using your old project or have you re-created the project from
>>> scratch?
>>> 
>>> It cannot reproduce the issue though.
>>> 
>>> Can you provide the stacktrace?
>>> What's your IDEA version?
>>> 
>>> For instance:
>>> git clone --depth 100 https://github.com/apache/calcite.git calcite-t1
>>> Open calcite-t1/build.gradle.kts in IDEA. Select "open as project".
>>> 
>>> Navigate to RelOptRulesTest, run it. It runs for me.
>>> Well, by default it uses Gradle to execute the tests, so it is expected to
>>> work.
>>> It is the default under "Build / Build Tools / Gradle -> Run tests using"
>>> option.
>>> 
>>> If I select "Run tests using" == "choose per test", right-click the test
>>> class and run it with IDEA runner, then it executes just fine (with IDEA
>>> runner).
>>> 
>>> If I select "build and run with == IDEA", re-execute the test, then IDEA
>>> creates out/... folder with classes, but the test still works.
>>> 
>>> In other words, all execution modes in IDEA work for me. I'm using IDEA
>>> 2019.3 EAP by the way.
>>> 
>>> Vladimir
>>> 
> 

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Danny Chan]

I always failed with this exception in the IDEA gradle build:
java.lang.ClassNotFoundException: 
org.gradle.api.internal.plugins.DefaultConvention

My JDK version is 1.8_0_6
My gradle version is 6.0.1

Here is the stacktrace:
java.lang.NoClassDefFoundError: 
org/gradle/api/internal/plugins/DefaultConvention
 at 
org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensionsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
 at 
org.jetbrains.plugins.gradle.tooling.internal.ExtraModelBuilder.buildAll(ExtraModelBuilder.java:67)
 at 
org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$BuildOperationWrappingToolingModelBuilder$1$1.create(DefaultToolingModelBuilderRegistry.java:104)
 at 
org.gradle.api.internal.project.DefaultProjectStateRegistry.withLenientState(DefaultProjectStateRegistry.java:134)
 at 
org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$BuildOperationWrappingToolingModelBuilder$1.call(DefaultToolingModelBuilderRegistry.java:100)
 at 
org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:416)
 at 
org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:406)
 at 
org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:165)
 at 
org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:250)
 at 
org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:158)
 at 
org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:102)
 at 
org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
 at 
org.gradle.tooling.provider.model.internal.DefaultToolingModelBuilderRegistry$BuildOperationWrappingToolingModelBuilder.buildAll(DefaultToolingModelBuilderRegistry.java:97)
 at 
org.gradle.tooling.internal.provider.runner.DefaultBuildController.getModel(DefaultBuildController.java:82)
 at 
org.gradle.tooling.internal.consumer.connection.InternalBuildActionAdapter$2.getModel(InternalBuildActionAdapter.java:77)
 at 
org.gradle.tooling.internal.consumer.connection.BuildControllerAdapter.getModel(BuildControllerAdapter.java:62)
 at 
org.gradle.tooling.internal.consumer.connection.AbstractBuildController.findModel(AbstractBuildController.java:57)
 at 
org.gradle.tooling.internal.consumer.connection.AbstractBuildController.findModel(AbstractBuildController.java:44)
 at 
org.jetbrains.plugins.gradle.model.ProjectImportAction.addExtraProject(ProjectImportAction.java:143)
 at 
org.jetbrains.plugins.gradle.model.ProjectImportAction.execute(ProjectImportAction.java:82)
 at 
org.jetbrains.plugins.gradle.model.ProjectImportAction.execute(ProjectImportAction.java:40)
 at 
org.gradle.tooling.internal.consumer.connection.InternalBuildActionAdapter.execute(InternalBuildActionAdapter.java:80)
 at 
org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner$ResultBuildingListener.buildResult(ClientProvidedBuildActionRunner.java:114)
 at 
org.gradle.tooling.internal.provider.runner.ClientProvidedBuildActionRunner$ResultBuildingListener.buildFinished(ClientProvidedBuildActionRunner.java:106)
 at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
 at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
 at 
org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:382)
 at 
org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:364)
 at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
 at 
org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:352)
 at 
org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:339)
 at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:42)
 at 
org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:231)
 at 
org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:150)
 at 
org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:58)
 at 
org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:325)
 at 
org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:235)
 at 
org

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

>Here is the stacktrace:
java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
s/DefaultConvention
 at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)

What is IDEA version?

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

>I also notice this output at the end, is this a known issue?
>Deprecated Gradle features were used in this build, making it incompatible
with Gradle 7.0.

It is.

>Also is there an easy way to specify number of threads for build and test
run?

Please find the documentation here:
https://docs.gradle.org/6.0.1/userguide/command_line_interface.html#sec:command_line_performance
and here
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parallel-execution

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Francis Chuang]

I thought I'd post about an issue I experienced with Gradle while 
testing the build/release process in docker.


I use Docker for Windows, which spins up a Hyper-V VM with docker and I 
interact with it using the docker CLI in WSL (Windows Subsystem for 
Linux). The setup is really neat, because I can use Windows as my main 
OS and almost have Linux running inside with almost native performance 
without having to use a VM.


A couple of days ago, Docker released 2.1.6.0 for their Docker for 
Windows Edge release and the build started hanging.


Basically, I execute the following to build and upload the release for 
voting (in the test environment):


gradle prepareVote -PasfTestSvnUsername=test -PasfTestSvnPassword=test 
-PasfTestNexusUsername=test -PasfTestNexusPassword=test 
-PasfTestGitSourceUsername=test -PasfTestGitSourcePassword=test 
-PasfCommitterId=test -PallowUncommittedChanges -Prc=0 -PuseGpgCmd 
-Psigning.gnupg.keyName=KEY_ID_GOES_HERE


The build will run, but it will hang forever after the configuration. 
Logs here:


2019-11-20T05:01:25.697+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute 'allprojects {}' action' completed
2019-11-20T05:01:25.699+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' started
2019-11-20T05:01:25.701+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Execute container callback action'
2019-11-20T05:01:25.701+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' completed
2019-11-20T05:01:25.701+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Apply plugin com.github.vlsi.ide to root 
project 'calcite-avatica''
2019-11-20T05:01:25.701+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Apply plugin com.github.vlsi.ide to root project 
'calcite-avatica'' completed
2019-11-20T05:01:25.702+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Apply plugin com.github.vlsi.crlf to root project 
'calcite-avatica'' started
2019-11-20T05:01:25.702+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Apply plugin com.github.vlsi.crlf to root 
project 'calcite-avatica''
2019-11-20T05:01:25.702+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Apply plugin com.github.vlsi.crlf to root project 
'calcite-avatica'' completed
2019-11-20T05:01:25.703+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Apply plugin com.github.vlsi.gradle-extensions to root 
project 'calcite-avatica'' started
2019-11-20T05:01:25.704+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Apply plugin 
com.github.vlsi.gradle-extensions to root project 'calcite-avatica''
2019-11-20T05:01:25.704+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Apply plugin com.github.vlsi.gradle-extensions to root 
project 'calcite-avatica'' completed
2019-11-20T05:01:25.706+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Apply plugin com.github.vlsi.stage-vote-release to root 
project 'calcite-avatica'' started
2019-11-20T05:01:25.728+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' started
2019-11-20T05:01:25.728+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Execute container callback action'
2019-11-20T05:01:25.728+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' completed
2019-11-20T05:01:25.728+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' started
2019-11-20T05:01:25.729+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Execute container callback action'
2019-11-20T05:01:25.729+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' completed
2019-11-20T05:01:25.729+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback action' started
2019-11-20T05:01:25.729+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] 
Completing Build operation 'Execute container callback action'
2019-11-20T05:01:25.729+ [DEBUG] 
[org.gradle.internal.operations.DefaultBuildOperationExecutor] Build 
operation 'Execute container callback act

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Danny Chan]

When I use the IDEA 2019.9 version, it works ~

But the travis test is failing for the slow test: here is my log 
https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification&utm_source=github_status

Best,
Danny Chan
在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov ，写道：
> > Here is the stacktrace:
> java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
> s/DefaultConvention
> at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
> nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
>
> What is IDEA version?
>
> Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Amir Gajst]

Hi

Trying to build the project with gradle on windows fails with the following
message:

> Task :core:spotlessJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':core:spotlessJava'.
> The following files had format violations:

core\build\generated\sources\version\org\apache\calcite\jdbc\CalciteDriverVersion.java
  @@ -1,41 +1,41 @@G [6s]sed in this build, making it incompatible
with Gradle 7.0.
  -/*\r\nde all' to show the individual deprecation warnings.
  - * Licensed to the Apache Software Foundation (ASF) under one or
more\r\nline_warnings
  - * contributor license agreements.  See the NOTICE file
distributed with\r\n
  - * this work for additional information regarding copyright
ownership.\r\n
  - * The ASF licenses this file to you under the Apache License,
Version 2.0\r\n
  - * (the "License"); you may not use this file except in
compliance with\r\n
  - * the License.  You may obtain a copy of the License at\r\n
  - *\r\n
  - * http://www.apache.org/licenses/LICENSE-2.0\r\n
  - *\r\nessTestResources
  - * Unless required by applicable law or agreed to in writing,
software\r\n
  - * distributed under the License is distributed on an "AS IS"
BASIS,\r\n
  - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied.\r\n
  - * See the License for the specific language governing
permissions and\r\n
  - * limitations under the License.\r\n
  - */\r\n
  -package org.apache.calcite.jdbc;\r\n
  -\r\n
  -import org.apache.calcite.avatica.DriverVersion;\r\n
  -\r\n
  -/**\r\n
  - * Provides information on the current Calcite version.\r\n
  - */\r\n
  -class CalciteDriverVersion {\r\n
  -  static final DriverVersion INSTANCE =\r\n
  -  new DriverVersion(\r\n
  -  "Calcite JDBC Driver",\r\n
  -  "1.22.0-SNAPSHOT" /* :version */,\r\n
  -  "Calcite",\r\n
  -  "1.22.0-SNAPSHOT" /* :version */,\r\n
  -  true,\r\n
  -  1 /* :major */,\r\n
  -  22 /* :minor */,\r\n
  -  1 /* :major */,\r\n
  -  22 /* :minor */);\r\n
  -\r\n
  -  private CalciteDriverVersion() {\r\n
  -  }\r\n
  -}\r\n
  -\r\n
  -// End CalciteDriverVersion.java\r\n
  +/*\n
  + * Licensed to the Apache Software Foundation (ASF) under one or
more\n
  + * contributor license agreements.  See the NOTICE file
distributed with\n
  + * this work for additional information regarding copyright
ownership.\n
  + * The ASF licenses this file to you under the Apache License,
Version 2.0\n
  + * (the "License"); you may not use this file except in
compliance with\n
  + * the License.  You may obtain a copy of the License at\n
  ... (34 more lines that didn't fit)
  Run 'gradlew spotlessApply' to fix these violations.

Needless to say I tried running gradlew spotlessApply and building again
and it had no effect ( the file
core\build\generated\sources\version\org\apache\calcite\jdbc\CalciteDriverVersion.java
which seems to be the problem is overwritten on every build...)

Best
Amir

On Wed, Nov 20, 2019 at 11:31 AM Danny Chan  wrote:

> When I use the IDEA 2019.9 version, it works ~
>
> But the travis test is failing for the slow test: here is my log
> https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification&utm_source=github_status
>
> Best,
> Danny Chan
> 在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov  >，写道：
> > > Here is the stacktrace:
> > java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
> > s/DefaultConvention
> > at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
> > nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
> >
> > What is IDEA version?
> >
> > Vladimir
>


-- 



[image: Sisense]

*Amir Gajst*
Software Engineer
+972-54-4766239
amir.gajst
[image: Instagram]    [image: LinkedIn]
   [image: Facebook]
   [image: Twitter]

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Are you using core.autocrlf true? (which is a recommended configuration for
Windows by the way:
https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings
)

>the file
core\build\generated\sources\version\org\apache\calcite\jdbc\CalciteDriverVersion.java
which seems to be the problem is overwritten on every build.

The file is taken
from core/src/main/version/org/apache/calcite/jdbc/CalciteDriverVersion.java,
and I would suggest checking which line endings the file has on your local
file system.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Amir Gajst]

I started with *core.autocrlf true* (and *core.eol lf*). I later switched
it to *core.autocrlf false* in one of the attempts to get it to build.
core/src/main/version/org/apache/calcite/jdbc/CalciteDriverVersion.java has
LF line endings but when it's copied
to 
core/build/generated/sources/version/org/apache/calcite/jdbc/CalciteDriverVersion.java
the line-ending is changed to CRLF. If I change it to LF and build again,
the file is overwritten and the line-ending is changed back to CRLF and the
build fails again.

On Wed, Nov 20, 2019 at 6:23 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Are you using core.autocrlf true? (which is a recommended configuration for
> Windows by the way:
>
> https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings
> )
>
> >the file
>
> core\build\generated\sources\version\org\apache\calcite\jdbc\CalciteDriverVersion.java
> which seems to be the problem is overwritten on every build.
>
> The file is taken
> from
> core/src/main/version/org/apache/calcite/jdbc/CalciteDriverVersion.java,
> and I would suggest checking which line endings the file has on your local
> file system.
>
> Vladimir
>


-- 



[image: Sisense]

*Amir Gajst*
Software Engineer
+972-54-4766239
amir.gajst
[image: Instagram]    [image: LinkedIn]
   [image: Facebook]
   [image: Twitter]

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

>I started with *core.autocrlf true*

Please ensure you are using core.autocrlf true, checkout the repository
from scratch, and retry.
It does work on my machine. It does work in GitHub Actions / Windows, it
does work at AppVeyor.

C:\temp>git config --get core.autocrlf
true

C:\temp>git config --get core.eol

C:\temp>git clone --depth 100 https://github.com/apache/calcite.git
calcite-tmp
Cloning into 'calcite-tmp'...

C:\temp>cd calcite-tmp

C:\temp\calcite-tmp>gradlew :core:versionClass :core:spotlessCheck
...

> Configure project :
Building Apache Calcite 1.22.0-SNAPSHOT
...
BUILD SUCCESSFUL
3 actionable tasks: 3 executed

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Amir Gajst]

Hi Vladimir,

It works.
FYI, it wasn't setting core.autocrlf to true that made the difference, but
unsetting core.eol.

Thanks

On Wed, Nov 20, 2019 at 7:41 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >I started with *core.autocrlf true*
>
> Please ensure you are using core.autocrlf true, checkout the repository
> from scratch, and retry.
> It does work on my machine. It does work in GitHub Actions / Windows, it
> does work at AppVeyor.
>
> C:\temp>git config --get core.autocrlf
> true
>
> C:\temp>git config --get core.eol
>
> C:\temp>git clone --depth 100 https://github.com/apache/calcite.git
> calcite-tmp 
> Cloning into 'calcite-tmp'...
>
> C:\temp>cd calcite-tmp
>
> C:\temp\calcite-tmp>gradlew :core:versionClass :core:spotlessCheck
> ...
>
> > Configure project :
> Building Apache Calcite 1.22.0-SNAPSHOT
> ...
> BUILD SUCCESSFUL
> 3 actionable tasks: 3 executed
>
> Vladimir
>


-- 



[image: Sisense]

*Amir Gajst*
Software Engineer
+972-54-4766239
amir.gajst
[image: Instagram]    [image: LinkedIn]
   [image: Facebook]
   [image: Twitter]

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Xiening Dai]

In case you didn’t know, JetBrains offers a free subscription to all Apache 
committers.

https://blog.jetbrains.com/blog/2019/05/30/jetbrains-supports-the-apache-software-foundation/
 
<https://blog.jetbrains.com/blog/2019/05/30/jetbrains-supports-the-apache-software-foundation/>


> On Nov 21, 2019, at 1:51 PM, Haisheng Yuan  wrote:
> 
> Thanks, Danny. Will try with newer version.
> 
> - Haisheng
> 
> --
> 发件人：Danny Chan
> 日　期：2019年11月21日 10:50:12
> 收件人：
> 主　题：Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts
> 
> Haisheng, upgrade to IDEA 2019.3 EAP solves the problem for me.
> 
> Best,
> Danny Chan
> 在 2019年11月21日 +0800 AM9:24，Haisheng Yuan ，写道：
>> Hi Vladimir,
>> 
>> I had the same error:
>> Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'.
>> 
>> IntelliJ IDEA 2018.3.4 (Community Edition)
>> Build #IC-183.5429.30, built on January 28, 2019
>> JRE: 1.8.0_152-release-1343-b26 x86_64
>> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
>> macOS 10.14.4
>> 
>> - Haisheng
>> 
>> ----------
>> 发件人：Danny Chan
>> 日　期：2019年11月20日 17:31:18
>> 收件人：
>> 主　题：Re: CALCITE-2905: Maven -> Gradle: any thoughts
>> 
>> When I use the IDEA 2019.9 version, it works ~
>> 
>> But the travis test is failing for the slow test: here is my log 
>> https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification&utm_source=github_status
>> 
>> Best,
>> Danny Chan
>> 在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov 
>> ，写道：
>>>> Here is the stacktrace:
>>> java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
>>> s/DefaultConvention
>>> at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
>>> nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
>>> 
>>> What is IDEA version?
>>> 
>>> Vladimir
>> 
> 

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Muhammad Gelbana]

I'm always in favor of anything that would lower our building time and
apparently, gradle supports parallel execution[1].
Will this ease the project importing process to Eclipse ? This is usually a
problem to me. I have to close projects to avoid displaying their build
errors, define source folders, run mvn eclipse:eclipse (and some say I
don't have to) and still have a couple of projects showing build errors in
Eclipse.

Do you know if Gradle will make lives easier to use with Eclipse ?

[1] https://guides.gradle.org/performance/#easy_improvements

Thanks,
Gelbana


On Sun, Mar 10, 2019 at 11:35 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Hi,
>
> I wonder what you think of migrating Maven to Gradle.
>
> I think one of the main points for having Gradle would be:
> 1) Eliminate "mvn install" for local testing. Calcite consists of
> multiple Maven modules, however Maven always uses jars from the local
> repository.
> That is if you modify a file in "core", then you can't just invoke mvn
> test from "cassandra". You have to "mvn install" "core" first.
> There are workarounds (e.g. "mvn install" all the modules every time)
>
> In Gradle, "multi-module" build feels more like "always composite
> module". In other words, even if you invoke "build" task from within
> "core" module, Gradle would find all the modules in current project,
> it would compute all the dependencies and build accordingly.
> In my opinion it makes a big difference.
>
> There's a support for cross-project incremental builds as well. I
> haven't used that, however the idea there is that one can have
> "calcite" and "drill" as different Gradle projects, however one can
> modify a file in Calcite and invoke "build" from a Drill folder. It
> would build Calcite first.
>
> 2) Maven task/plugins often fail to declare inputs/outputs. This
> causes issues like MSHARED-394: Avoid rewrite of destination in
> DefaultMavenFileFilter#filterFile when producing the same contents.
> Gradle embrases tasks authors to declare inputs outputs (e.g. files or
> just property values) and it enables the build system to track stale
> tasks.
>
> Gradle supports "buildSrc" folder which can contain code that is
> available to the buildfiles of a current project. It enables to
> express build logic in a much more sound programming language than
> XML.
>
> Vladimir
>

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Muhammad>gradle supports parallel execution

The good thing is Gradle can run tests from "core" in parallel with javadoc
build for "cassandra" and so on.

Muhammad> Will this ease the project importing process to Eclipse ? This is
usually a
Muhammad> problem to me. I have to close projects to avoid displaying their
build
Muhammad> errors, define source folders, run mvn eclipse:eclipse (and some
say I
Muhammad> don't have to) and still have a couple of projects showing build
errors in
Muhammad> Eclipse.

I don't use Eclipse, however:
1) They say Gradle projects could be imported to Eclipse just fine.
I'm updating Apache JMeter's build system to Gradle at the moment (see
https://github.com/apache/jmeter/pull/448 ),
and you can try importing the project to see how it feels like (see gradle
branch https://github.com/vlsi/jmeter/tree/gradle ).

You can try importing https://github.com/ben-manes/caffeine/ , or
https://github.com/spring-projects/spring-framework/ or whatever you like.
However I'm inclined to Kotlin-based DSL, as it has way less magic than in
Groovy-based scripts.

2) Gradle is very easy to customize. That is if default import somehow
fails, the build script can contain customizations to make import better.
For instance, you can check
https://github.com/ben-manes/caffeine/blob/master/gradle/eclipse.gradle

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Michael Mior]

I currently sit at -0 on this as I haven't found Maven too cumbersome
personally. However, I think you make some valid points. Hopefully it
won't take too long to try this and then we can see what the actual
impact on build times will be. It would also be good to hear from
others doing regular Calcite development.

--
Michael Mior
mm...@apache.org

Le dim. 10 mars 2019 à 05:35, Vladimir Sitnikov
 a écrit :
>
> Hi,
>
> I wonder what you think of migrating Maven to Gradle.
>
> I think one of the main points for having Gradle would be:
> 1) Eliminate "mvn install" for local testing. Calcite consists of
> multiple Maven modules, however Maven always uses jars from the local
> repository.
> That is if you modify a file in "core", then you can't just invoke mvn
> test from "cassandra". You have to "mvn install" "core" first.
> There are workarounds (e.g. "mvn install" all the modules every time)
>
> In Gradle, "multi-module" build feels more like "always composite
> module". In other words, even if you invoke "build" task from within
> "core" module, Gradle would find all the modules in current project,
> it would compute all the dependencies and build accordingly.
> In my opinion it makes a big difference.
>
> There's a support for cross-project incremental builds as well. I
> haven't used that, however the idea there is that one can have
> "calcite" and "drill" as different Gradle projects, however one can
> modify a file in Calcite and invoke "build" from a Drill folder. It
> would build Calcite first.
>
> 2) Maven task/plugins often fail to declare inputs/outputs. This
> causes issues like MSHARED-394: Avoid rewrite of destination in
> DefaultMavenFileFilter#filterFile when producing the same contents.
> Gradle embrases tasks authors to declare inputs outputs (e.g. files or
> just property values) and it enables the build system to track stale
> tasks.
>
> Gradle supports "buildSrc" folder which can contain code that is
> available to the buildfiles of a current project. It enables to
> express build logic in a much more sound programming language than
> XML.
>
> Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Francis Chuang]

I don't have an opinion on this, as I don't actively contribute to 
Calcite. However, when I built the last few Avatica releases, it took a 
while for maven to produce the build. If moving to Gradle yields 
performance improvements, I hope Avatica can also be moved to Gradle too.


Francis

On 11/03/2019 9:00 am, Michael Mior wrote:

I currently sit at -0 on this as I haven't found Maven too cumbersome
personally. However, I think you make some valid points. Hopefully it
won't take too long to try this and then we can see what the actual
impact on build times will be. It would also be good to hear from
others doing regular Calcite development.

--
Michael Mior
mm...@apache.org

Le dim. 10 mars 2019 à 05:35, Vladimir Sitnikov
 a écrit :


Hi,

I wonder what you think of migrating Maven to Gradle.

I think one of the main points for having Gradle would be:
1) Eliminate "mvn install" for local testing. Calcite consists of
multiple Maven modules, however Maven always uses jars from the local
repository.
That is if you modify a file in "core", then you can't just invoke mvn
test from "cassandra". You have to "mvn install" "core" first.
There are workarounds (e.g. "mvn install" all the modules every time)

In Gradle, "multi-module" build feels more like "always composite
module". In other words, even if you invoke "build" task from within
"core" module, Gradle would find all the modules in current project,
it would compute all the dependencies and build accordingly.
In my opinion it makes a big difference.

There's a support for cross-project incremental builds as well. I
haven't used that, however the idea there is that one can have
"calcite" and "drill" as different Gradle projects, however one can
modify a file in Calcite and invoke "build" from a Drill folder. It
would build Calcite first.

2) Maven task/plugins often fail to declare inputs/outputs. This
causes issues like MSHARED-394: Avoid rewrite of destination in
DefaultMavenFileFilter#filterFile when producing the same contents.
Gradle embrases tasks authors to declare inputs outputs (e.g. files or
just property values) and it enables the build system to track stale
tasks.

Gradle supports "buildSrc" folder which can contain code that is
available to the buildfiles of a current project. It enables to
express build logic in a much more sound programming language than
XML.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Kenneth Knowles]

I don't modify Calcite often enough to deserve a full vote, but I am +0.5
as an occasional contributor.

Beam transitioned from Maven to Gradle. We saw clean build times speed up
by 5x or so. And of course clean builds are irrelevant for correct build
systems, as their whole purpose is to build what is necessary from any
starting state and not rebuild anything not necessary. The time savings for
real workflows with lots of rebuilding after just a couple files edited is
much greater.

Gradle is mature and has all the plugins you need, and it is easy to write
custom logic (groovy versus xml) or even a plugin if something is not quite
what you need. There are no technical reasons not to switch, but if some
portion of your community prefers Maven then it has a cost because they
will have a harder time contributing to the build system and will be
frustrated at learning a new command-line interface. That matters a lot.

I have some advice if you go ahead:

 - Do *not* try to do a byte-for-byte compatible build. We did that,
somewhat. It added a ton of migration time and complexity for almost zero
value.
 - *Do* try to learn Gradle and make your build as simple and canonical as
possible. We did not do that. Instead we have a highly custom build setup,
even when we are doing ordinary things. It means only a few specialists
really work on our build.

I think the migration can be quick and easy if you allow it to be. I'd be
happy to help here and there.

Kenn


On Sun, Mar 10, 2019 at 3:13 PM Francis Chuang 
wrote:

> I don't have an opinion on this, as I don't actively contribute to
> Calcite. However, when I built the last few Avatica releases, it took a
> while for maven to produce the build. If moving to Gradle yields
> performance improvements, I hope Avatica can also be moved to Gradle too.
>
> Francis
>
> On 11/03/2019 9:00 am, Michael Mior wrote:
> > I currently sit at -0 on this as I haven't found Maven too cumbersome
> > personally. However, I think you make some valid points. Hopefully it
> > won't take too long to try this and then we can see what the actual
> > impact on build times will be. It would also be good to hear from
> > others doing regular Calcite development.
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le dim. 10 mars 2019 à 05:35, Vladimir Sitnikov
> >  a écrit :
> >>
> >> Hi,
> >>
> >> I wonder what you think of migrating Maven to Gradle.
> >>
> >> I think one of the main points for having Gradle would be:
> >> 1) Eliminate "mvn install" for local testing. Calcite consists of
> >> multiple Maven modules, however Maven always uses jars from the local
> >> repository.
> >> That is if you modify a file in "core", then you can't just invoke mvn
> >> test from "cassandra". You have to "mvn install" "core" first.
> >> There are workarounds (e.g. "mvn install" all the modules every time)
> >>
> >> In Gradle, "multi-module" build feels more like "always composite
> >> module". In other words, even if you invoke "build" task from within
> >> "core" module, Gradle would find all the modules in current project,
> >> it would compute all the dependencies and build accordingly.
> >> In my opinion it makes a big difference.
> >>
> >> There's a support for cross-project incremental builds as well. I
> >> haven't used that, however the idea there is that one can have
> >> "calcite" and "drill" as different Gradle projects, however one can
> >> modify a file in Calcite and invoke "build" from a Drill folder. It
> >> would build Calcite first.
> >>
> >> 2) Maven task/plugins often fail to declare inputs/outputs. This
> >> causes issues like MSHARED-394: Avoid rewrite of destination in
> >> DefaultMavenFileFilter#filterFile when producing the same contents.
> >> Gradle embrases tasks authors to declare inputs outputs (e.g. files or
> >> just property values) and it enables the build system to track stale
> >> tasks.
> >>
> >> Gradle supports "buildSrc" folder which can contain code that is
> >> available to the buildfiles of a current project. It enables to
> >> express build logic in a much more sound programming language than
> >> XML.
> >>
> >> Vladimir
>
>

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Zoltan Haindrich]

I'm happy that this have came up - I think Gradle is much more transparent than Maven in 
general; with no "built-in" limitations
My experience with maven is that I'm looking for some plugin which might do something similar what is needed...and depending on "lifecycle/etc" things it might actually 
work...in gradle as a last resort people could write a new task and hook it into the build graph - which is more straight forward.
What I further find very usefull in Gradle; is that the build is actually most of the time quite silent - messages on the screen has more meaning and they don't just eat up 
space for no good reason...and it's not xml.


As a matter of fact I'm also using Eclipse; and to make calcite-core up and running with it: I've to remove 3 invalid source refernces; add 1 missing and exclude some files 
from the buildpathso it doesn't work out of the box :)

I will be happy to help migrating - or at least fix Eclipse support :D
+1

cheers,
Zoltan

On 3/10/19 11:49 AM, Vladimir Sitnikov wrote:

Muhammad>gradle supports parallel execution

The good thing is Gradle can run tests from "core" in parallel with javadoc
build for "cassandra" and so on.

Muhammad> Will this ease the project importing process to Eclipse ? This is
usually a
Muhammad> problem to me. I have to close projects to avoid displaying their
build
Muhammad> errors, define source folders, run mvn eclipse:eclipse (and some
say I
Muhammad> don't have to) and still have a couple of projects showing build
errors in
Muhammad> Eclipse.

I don't use Eclipse, however:
1) They say Gradle projects could be imported to Eclipse just fine.
I'm updating Apache JMeter's build system to Gradle at the moment (see
https://github.com/apache/jmeter/pull/448 ),
and you can try importing the project to see how it feels like (see gradle
branch https://github.com/vlsi/jmeter/tree/gradle ).

You can try importing https://github.com/ben-manes/caffeine/ , or
https://github.com/spring-projects/spring-framework/ or whatever you like.
However I'm inclined to Kotlin-based DSL, as it has way less magic than in
Groovy-based scripts.

2) Gradle is very easy to customize. That is if default import somehow
fails, the build script can contain customizations to make import better.
For instance, you can check
https://github.com/ben-manes/caffeine/blob/master/gradle/eclipse.gradle

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Michael Mior]

Zoltan,

Please file a JIRA case for any issues you encounter when using
Eclipse. Regardless of whether we move forward with Gradle, it would
be good to have this working painlessly, hopefully with some
instructions added to the HOWTO below.

https://calcite.apache.org/docs/howto.html#setting-up-an-ide-for-contributing

--
Michael Mior
mm...@apache.org

Le lun. 11 mars 2019 à 12:17, Zoltan Haindrich  a écrit :
>
> I'm happy that this have came up - I think Gradle is much more transparent 
> than Maven in general; with no "built-in" limitations
> My experience with maven is that I'm looking for some plugin which might do 
> something similar what is needed...and depending on "lifecycle/etc" things it 
> might actually
> work...in gradle as a last resort people could write a new task and hook it 
> into the build graph - which is more straight forward.
> What I further find very usefull in Gradle; is that the build is actually 
> most of the time quite silent - messages on the screen has more meaning and 
> they don't just eat up
> space for no good reason...and it's not xml.
>
> As a matter of fact I'm also using Eclipse; and to make calcite-core up and 
> running with it: I've to remove 3 invalid source refernces; add 1 missing and 
> exclude some files
> from the buildpathso it doesn't work out of the box :)
> I will be happy to help migrating - or at least fix Eclipse support :D
> +1
>
> cheers,
> Zoltan
>
> On 3/10/19 11:49 AM, Vladimir Sitnikov wrote:
> > Muhammad>gradle supports parallel execution
> >
> > The good thing is Gradle can run tests from "core" in parallel with javadoc
> > build for "cassandra" and so on.
> >
> > Muhammad> Will this ease the project importing process to Eclipse ? This is
> > usually a
> > Muhammad> problem to me. I have to close projects to avoid displaying their
> > build
> > Muhammad> errors, define source folders, run mvn eclipse:eclipse (and some
> > say I
> > Muhammad> don't have to) and still have a couple of projects showing build
> > errors in
> > Muhammad> Eclipse.
> >
> > I don't use Eclipse, however:
> > 1) They say Gradle projects could be imported to Eclipse just fine.
> > I'm updating Apache JMeter's build system to Gradle at the moment (see
> > https://github.com/apache/jmeter/pull/448 ),
> > and you can try importing the project to see how it feels like (see gradle
> > branch https://github.com/vlsi/jmeter/tree/gradle ).
> >
> > You can try importing https://github.com/ben-manes/caffeine/ , or
> > https://github.com/spring-projects/spring-framework/ or whatever you like.
> > However I'm inclined to Kotlin-based DSL, as it has way less magic than in
> > Groovy-based scripts.
> >
> > 2) Gradle is very easy to customize. That is if default import somehow
> > fails, the build script can contain customizations to make import better.
> > For instance, you can check
> > https://github.com/ben-manes/caffeine/blob/master/gradle/eclipse.gradle
> >
> > Vladimir
> >

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Julian Hyde]

I’m +0.25

If it were left to me alone, I’d be in the “if it ain’t broke…” camp. But I’m 
glad people want to modernize, and I won’t stand in their way.

One of the awesome things about maven has been how my IDE (Intellij) can load 
projects automatically. I would not tolerate any back-sliding on that dimension.

It was tricky to get the release process working in Maven. Anyone who has not 
been a release manager might not realize this. There are details like signing, 
upload of tar balls to svn, upload of jars to nexus, the naming of tar and jar 
files, and the contents of those files, and generating an intermediate git 
commit so that the release is exactly based on a labeled git commit. We’ll also 
need to generate pom.xml files for nexus and ultimately maven central. The 
gradle build will need to create the same results even if it does not use the 
same means.

Julian


> On Mar 11, 2019, at 11:07 AM, Michael Mior  wrote:
> 
> Zoltan,
> 
> Please file a JIRA case for any issues you encounter when using
> Eclipse. Regardless of whether we move forward with Gradle, it would
> be good to have this working painlessly, hopefully with some
> instructions added to the HOWTO below.
> 
> https://calcite.apache.org/docs/howto.html#setting-up-an-ide-for-contributing
> 
> --
> Michael Mior
> mm...@apache.org
> 
> Le lun. 11 mars 2019 à 12:17, Zoltan Haindrich  a écrit :
>> 
>> I'm happy that this have came up - I think Gradle is much more transparent 
>> than Maven in general; with no "built-in" limitations
>> My experience with maven is that I'm looking for some plugin which might do 
>> something similar what is needed...and depending on "lifecycle/etc" things 
>> it might actually
>> work...in gradle as a last resort people could write a new task and hook it 
>> into the build graph - which is more straight forward.
>> What I further find very usefull in Gradle; is that the build is actually 
>> most of the time quite silent - messages on the screen has more meaning and 
>> they don't just eat up
>> space for no good reason...and it's not xml.
>> 
>> As a matter of fact I'm also using Eclipse; and to make calcite-core up and 
>> running with it: I've to remove 3 invalid source refernces; add 1 missing 
>> and exclude some files
>> from the buildpathso it doesn't work out of the box :)
>> I will be happy to help migrating - or at least fix Eclipse support :D
>> +1
>> 
>> cheers,
>> Zoltan
>> 
>> On 3/10/19 11:49 AM, Vladimir Sitnikov wrote:
>>> Muhammad>gradle supports parallel execution
>>> 
>>> The good thing is Gradle can run tests from "core" in parallel with javadoc
>>> build for "cassandra" and so on.
>>> 
>>> Muhammad> Will this ease the project importing process to Eclipse ? This is
>>> usually a
>>> Muhammad> problem to me. I have to close projects to avoid displaying their
>>> build
>>> Muhammad> errors, define source folders, run mvn eclipse:eclipse (and some
>>> say I
>>> Muhammad> don't have to) and still have a couple of projects showing build
>>> errors in
>>> Muhammad> Eclipse.
>>> 
>>> I don't use Eclipse, however:
>>> 1) They say Gradle projects could be imported to Eclipse just fine.
>>> I'm updating Apache JMeter's build system to Gradle at the moment (see
>>> https://github.com/apache/jmeter/pull/448 ),
>>> and you can try importing the project to see how it feels like (see gradle
>>> branch https://github.com/vlsi/jmeter/tree/gradle ).
>>> 
>>> You can try importing https://github.com/ben-manes/caffeine/ , or
>>> https://github.com/spring-projects/spring-framework/ or whatever you like.
>>> However I'm inclined to Kotlin-based DSL, as it has way less magic than in
>>> Groovy-based scripts.
>>> 
>>> 2) Gradle is very easy to customize. That is if default import somehow
>>> fails, the build script can contain customizations to make import better.
>>> For instance, you can check
>>> https://github.com/ben-manes/caffeine/blob/master/gradle/eclipse.gradle
>>> 
>>> Vladimir
>>> 

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Vladimir Sitnikov]

Julian> One of the awesome things about maven has been how my IDE
(Intellij) can load projects automatically

You know what? Not only I can load Gradle-based project automatically.

I can debug (!!) Gradle build script right from my Intellij.
Oh, I just set a breakpoint inside a build script, and watch variables,
perform it step by step, etc.
This is really amazing.

It is not like I do it often, but, you know. Being able to write unit tests
for build system could help as well.

Julian>my IDE (Intellij) can load projects automatically

There's extra integration like gradle script can update IntelliJ (and
Eclipse) configuration via dedicated APIs.
For instance, gradle script can automatically configure proper "license
headers" for the project.
It does improve experience.

Julian>It was tricky to get the release process working in Maven. Anyone
who has not been a release manager might not realize this

It is true what you say. I've pushed stuff to Central via Maven, and I do
agree maven-release-plugin/nexus-staging/whatever are quite complicated to
configure for non-trivial projects.

However, it looks like Gradle can simplify lots of release steps. There are
plugins (think of it like of a "jar with code"), and we can just add our
own code to buildSrc folder in Calcite repository which automatically
becomes a part of a build system. Then we can do whatever logic we need.

Julian>There are details like signing, upload of tar balls to svn, upload
of jars to nexus, the naming of tar and jar files, and the contents of
those files, and generating an intermediate git commit so that the release
is exactly based on a labeled git commit.

That's what I design for JMeter right now. I don't have exact code samples
to share yet.

In Gradle, "project version" is a java.lang.Object, so its toString
represents the version. That is we don't have to actually update version in
the source code.
We can just always have "current version" in the source code which
automatically becomes a non-snapshot one when the build is triggered with a
"release" parameter.

That enables us to just add a tag on "preexisting" git commit, and build it
as "release candidate 1". That's it.
If that succeeds we can build exactly that commit id as a "release".
Rollback is trivial: we just drop staging repository from Nexus, and we
remove files from dist.apache.org. There's no need to dance with source
code branches.
We don't really have to remove the tag.

On top of that, Gradle has reproducible builds option.
For instance, when I build JMeter source/binary artifacts (zip, tgz files),
I get exactly the same SHA. Isn't that cool?

Julian>We’ll also need to generate pom.xml files for nexus and ultimately
maven central

I don't suggest to start collecting the checklist here. I do know it will
be quite big (e.g. you check out https://github.com/apache/jmeter/pull/448)

I don't think there will be technical limitations that would prevent use of
Gradle.
It would be valuable though if someone could share something on the
negative experience though.

Vladimir

Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Kenneth Knowles]

FWIW Beam also has gpg signing which is a one liner [1] and generates a pom
[2] where the latter is very manual unfortunately. We've used all this for
the last 5 releases.

One negative is that default of very high parallelism, while good for
end-to-end time, can cause OOMs and require JVM heap increases, or blow
Jenkins workers if there are concurrent builds.

Kenn

[1]
https://github.com/apache/beam/blob/master/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L1108
[2]
https://github.com/apache/beam/blob/master/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L986

On Mon, Mar 11, 2019 at 2:20 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Julian> One of the awesome things about maven has been how my IDE
> (Intellij) can load projects automatically
>
> You know what? Not only I can load Gradle-based project automatically.
>
> I can debug (!!) Gradle build script right from my Intellij.
> Oh, I just set a breakpoint inside a build script, and watch variables,
> perform it step by step, etc.
> This is really amazing.
>
> It is not like I do it often, but, you know. Being able to write unit tests
> for build system could help as well.
>
> Julian>my IDE (Intellij) can load projects automatically
>
> There's extra integration like gradle script can update IntelliJ (and
> Eclipse) configuration via dedicated APIs.
> For instance, gradle script can automatically configure proper "license
> headers" for the project.
> It does improve experience.
>
> Julian>It was tricky to get the release process working in Maven. Anyone
> who has not been a release manager might not realize this
>
> It is true what you say. I've pushed stuff to Central via Maven, and I do
> agree maven-release-plugin/nexus-staging/whatever are quite complicated to
> configure for non-trivial projects.
>
> However, it looks like Gradle can simplify lots of release steps. There are
> plugins (think of it like of a "jar with code"), and we can just add our
> own code to buildSrc folder in Calcite repository which automatically
> becomes a part of a build system. Then we can do whatever logic we need.
>
> Julian>There are details like signing, upload of tar balls to svn, upload
> of jars to nexus, the naming of tar and jar files, and the contents of
> those files, and generating an intermediate git commit so that the release
> is exactly based on a labeled git commit.
>
> That's what I design for JMeter right now. I don't have exact code samples
> to share yet.
>
> In Gradle, "project version" is a java.lang.Object, so its toString
> represents the version. That is we don't have to actually update version in
> the source code.
> We can just always have "current version" in the source code which
> automatically becomes a non-snapshot one when the build is triggered with a
> "release" parameter.
>
> That enables us to just add a tag on "preexisting" git commit, and build it
> as "release candidate 1". That's it.
> If that succeeds we can build exactly that commit id as a "release".
> Rollback is trivial: we just drop staging repository from Nexus, and we
> remove files from dist.apache.org. There's no need to dance with source
> code branches.
> We don't really have to remove the tag.
>
> On top of that, Gradle has reproducible builds option.
> For instance, when I build JMeter source/binary artifacts (zip, tgz files),
> I get exactly the same SHA. Isn't that cool?
>
> Julian>We’ll also need to generate pom.xml files for nexus and ultimately
> maven central
>
> I don't suggest to start collecting the checklist here. I do know it will
> be quite big (e.g. you check out https://github.com/apache/jmeter/pull/448
> )
>
> I don't think there will be technical limitations that would prevent use of
> Gradle.
> It would be valuable though if someone could share something on the
> negative experience though.
>
> Vladimir
>

Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Haisheng Yuan]

Hi Vladimir,

I had the same error:
Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'.

IntelliJ IDEA 2018.3.4 (Community Edition)
Build #IC-183.5429.30, built on January 28, 2019
JRE: 1.8.0_152-release-1343-b26 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.4

- Haisheng

--
发件人：Danny Chan
日　期：2019年11月20日 17:31:18
收件人：
主　题：Re: CALCITE-2905: Maven -> Gradle: any thoughts

When I use the IDEA 2019.9 version, it works ~

But the travis test is failing for the slow test: here is my log 
https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification&utm_source=github_status

Best,
Danny Chan
在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov ，写道：
> > Here is the stacktrace:
> java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
> s/DefaultConvention
> at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
> nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
>
> What is IDEA version?
>
> Vladimir

Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Danny Chan]

Haisheng, upgrade to IDEA 2019.3 EAP solves the problem for me.

Best,
Danny Chan
在 2019年11月21日 +0800 AM9:24，Haisheng Yuan ，写道：
> Hi Vladimir,
>
> I had the same error:
> Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'.
>
> IntelliJ IDEA 2018.3.4 (Community Edition)
> Build #IC-183.5429.30, built on January 28, 2019
> JRE: 1.8.0_152-release-1343-b26 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.4
>
> - Haisheng
>
> --
> 发件人：Danny Chan
> 日　期：2019年11月20日 17:31:18
> 收件人：
> 主　题：Re: CALCITE-2905: Maven -> Gradle: any thoughts
>
> When I use the IDEA 2019.9 version, it works ~
>
> But the travis test is failing for the slow test: here is my log 
> https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification&utm_source=github_status
>
> Best,
> Danny Chan
> 在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov ，写道：
> > > Here is the stacktrace:
> > java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
> > s/DefaultConvention
> > at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
> > nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
> >
> > What is IDEA version?
> >
> > Vladimir
>

Re: Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts

[Haisheng Yuan]

Thanks, Danny. Will try with newer version.

- Haisheng

--
发件人：Danny Chan
日　期：2019年11月21日 10:50:12
收件人：
主　题：Re: Re: CALCITE-2905: Maven -> Gradle: any thoughts

Haisheng, upgrade to IDEA 2019.3 EAP solves the problem for me.

Best,
Danny Chan
在 2019年11月21日 +0800 AM9:24，Haisheng Yuan ，写道：
> Hi Vladimir,
>
> I had the same error:
> Unable to load class 'org.gradle.api.internal.plugins.DefaultConvention'.
>
> IntelliJ IDEA 2018.3.4 (Community Edition)
> Build #IC-183.5429.30, built on January 28, 2019
> JRE: 1.8.0_152-release-1343-b26 x86_64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> macOS 10.14.4
>
> - Haisheng
>
> --
> 发件人：Danny Chan
> 日　期：2019年11月20日 17:31:18
> 收件人：
> 主　题：Re: CALCITE-2905: Maven -> Gradle: any thoughts
>
> When I use the IDEA 2019.9 version, it works ~
>
> But the travis test is failing for the slow test: here is my log 
> https://travis-ci.org/apache/calcite/jobs/614406384?utm_medium=notification&utm_source=github_status
>
> Best,
> Danny Chan
> 在 2019年11月20日 +0800 PM2:28，Vladimir Sitnikov ，写道：
> > > Here is the stacktrace:
> > java.lang.NoClassDefFoundError: org/gradle/api/internal/plugin
> > s/DefaultConvention
> > at org.jetbrains.plugins.gradle.tooling.builder.ProjectExtensio
> > nsDataBuilderImpl.buildAll(ProjectExtensionsDataBuilderImpl.groovy:50)
> >
> > What is IDEA version?
> >
> > Vladimir
>