calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis Chuang <>
Subject Re: CALCITE-2905: Maven -> Gradle: any thoughts
Date Thu, 30 May 2019 11:04:11 GMT
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.


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
> )
> I have commands like "./gradlew prepareVote" that builds artifacts, stages
> them to /, 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 (
> ), so everybody can try
> that out with zero risks of updating 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

View raw message