[jira] [Commented] (KAFKA-855) Ant+Ivy build for Kafka

["David Arthur (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802993#comment-13802993 ] 

David Arthur commented on KAFKA-855:
------------------------------------

Is everyone happy with the current build (SBT), or is there still interest in creating an Ant/Ivy build?

> Ant+Ivy build for Kafka
> -----------------------
>
>                 Key: KAFKA-855
>                 URL: https://issues.apache.org/jira/browse/KAFKA-855
>             Project: Kafka
>          Issue Type: Improvement
>    Affects Versions: 0.9
>            Reporter: David Arthur
>              Labels: build, experimental
>             Fix For: 0.9
>
>         Attachments: 0001-Compile-and-package-Kafka-with-Ant-Ivy.patch, 0002-Tests-all-passing.patch, 0003-Parameterize-scala-version-add-offline-mode.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Kafka has very simple build requirements and a system like Ant is well suited for a clean and concise build. I have an experimental patch that does just this - replaces SBT with Ant+Ivy. IMO, this approach is cleaner, clearer, and more developer friendly.
> Dependencies are localized to one directory in the project rather than living in ~/.ivy2 and elsewhere. This makes manual classpath building very simple (just one glob) and also makes packaging the libs very easy.
> Testing is done through junit rather than scalatest. The Kafka tests use `org.scalatest.junit.JUnitSuite` which allow the tests to be executed through the junit test runner.
> Management of the Scala version is handled through Ivy. The way I have laid out the Ant script, the Scala version can be changed by setting a different runtime property (-Dscala.version=2.8.2). Cross-compilation of the Kafka artifact would be simple to add.
> The one downside to this approach is lack of an incremental build. `scalac` is deprecating its incremental build capabilities in coming versions. The suggested solution to this is to use an IDE that supports incremental builds.
> The main motivation for this approach, to me at least, is that a developer can look at build.xml and immediately understand what is going on (with the exception maybe of the <ivy: .../> actions which would not be changing). This is largely not true for SBT unless someone is already familiar with SBT. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)