[
https://issues.apache.org/jira/browse/KAFKA-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Arthur updated KAFKA-855:
-------------------------------
Attachment: 0003-Parameterize-scala-version-add-offline-mode.patch
0002-Tests-all-passing.patch
0001-Compile-and-package-Kafka-with-Ant-Ivy.patch
Attaching initial patch set
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
