On Wed, Aug 13, 2014 at 9:59 PM, Robert Stupp <sn...@snazy.de> wrote:
> Hi, > > Since there were some IRC posts regarding "realclean" when dependencies > change, I thought about replacing ant with something else. > It's not just because of that particular realclean but also on > dependencies that don't get actually updated or even out-of-date IDE > project files (.classpath) causing problems. > > This "something better" should have proper dependency management, doesn't > require us to have dependency jars in git and be supported my major IDEs > (IDEA / Eclipse). (Someone using Eclipse?). > But such a change should not result in a folder or code refactoring game... > > Maven could be an option - but it has some drawbacks regarding the current > folder structure. > Maven can basically only emit one artifact per pom properly (plus some > other files like -javadoc.jar or -sources.jar). > So it might be required to change the folder structure (don't want that - > merging would become a nightmare, if possible at all...). > > Grade would be a nice option. > It is more a scripting language than a "static" construct like Maven's > pom.xml. > It is very flexible and seems to have all required features. > Gradle has native support for Maven repositories. > Gradle does not require the user to install Gradle (you can, but do not > need to) - it comes with a small "wrapper" that fetches a Gradle binary. > > I've identified these "non-standard" blocks in build.xml: > > - gen-cli-grammar: basically just a conditional exec > - gen-cql3-grammar: basically just a conditional exec > - generate-cql-html: basically just an exec > - write-java-license-headers / rat: basically just an exec > - emitting multiple jars (cassandra.jar, cassandra-thrift.jar, > cassandra-clientutil.jar) from the same folder (build/classes/main+thrift): > difficult with Maven > - gen-thrift-py: basically just an exec > - several test targets: is possible with Maven, but let's the pom.xml > "explode" and is not easy to read > > By using Gradle I hope to > > - get rid of dependency problems > - "realclean" > - dependency differences between build.xml and IDE since > .project/.classpath not updated > - .project/.classpath cannot be generated because compilation fails > due to dependency changes > - make the build file smaller > - remove binaries (dependencies) from git > - proper IDE support for IDEA + Eclipse? > > > If Gradle works, it could be introduced like that: > > 1. Keep both build.xml and Gradle build file up to date > 2. After a while change build.xml to act basically just as a "wrapper" > for Gradle. Just to not "disturb" existing processes (Jenkins/CI) and give > users a chance to recognize the change. > 3. Remove build.xml after some time > > > Would be great to get some feedback what you think about this. > Not strongly against though not fully enthusiastic either. The current build file is certainly big and messy but I don't feel like this is a big burden in practice (it's rarely changed or in trivial ways), nor do I feel that running 'ant realcean' once in a while is a big deal (especially since we are trying to be conservative on when we upgrade dependencies on purpose). On the flip side, the parts about maintaining 2 build files for a while and ultimately having to change all existing process/habits don't sound particularly fun (not even counting the initial rewrite and checking we haven't lost anything in the transition). I can't really comment on whether "out-of-date IDE project files causing problems" is a huge deal however. -- Sylvain
