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 <[email protected]> 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 > [email protected] > > Le lun. 11 mars 2019 à 12:17, Zoltan Haindrich <[email protected]> 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 buildpath....so 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 >>>
