Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> Re: Thoughts on using Ant+Ivy for the build?

Copy link to this message
Re: Thoughts on using Ant+Ivy for the build?
Ant and Ivy also bring in lots of free stuff as well as the flexibility
to do non-standard things

It seems that SBT is a moving target (as is Scala itself, being such a
new tech), and keeping up with SBT changes and people's plugins hosted
on GitHub sounds like a pain. Maven and Ant/Ivy are mature and stable
and well understood.

Without digressing too much into a Maven/Ant+Ivy/SBT debate, it is clear
that there are issues with the current build. I'm proposing Ant+Ivy, if
enough people buy into this - great we'll use Ant. If not, also great -
I'm simply forcing the dialog :)

Also, if what I'm proposing is accepted, I would be willing to maintain
this piece of the project in the longer term.


On 4/8/13 3:40 PM, Scott Carey wrote:
> My first reaction to looking at the current build was that I could do a
> lot better with Maven and I'd get a lot of free stuff with that
> (dependency:tree, versions:display-dependency-updates), except that cross
> scala versions would be uglier.  Modularization is trivial with maven (the
> stuff outside core).
> A little more digging, and it seems that the current sbt build could be
> significantly simplified and has a lot of cruft.
> On 4/5/13 12:55 PM, "David Arthur" <[EMAIL PROTECTED]> wrote:
>> After getting frustrated with SBT, and being unable to figure out
>> seemingly simple problems like KAFKA-843, I decided to try something
>> completely different.
>> I spent some time yesterday adapting some Ant/Ivy boilerplate I use for
>> projects to Kafka. It was actually pretty easy to get working (Kafka is
>> a very simple build), and I think it's _much_ cleaner than the existing
>> SBT stuff.
>> Attached is a patchset of the work I did. N.B., this is totally
>> experimental and only considers the "core" part of the project.
>> At this point I can:
>> * Resolve all deps through Ivy (except yammer.metrics which is checked in)
>> * Resolve different versions of Scala through Ivy (i.e., cross
>> compile-ability)
>> * Compile the source
>> * Run all the unit tests (all passing)
>> * Compile a jar
>> * Package a tarball of the libs, conf, and bin scripts
>> Since all the libraries are localized to the project (and not in
>> ~/.ivy2), the packaging is trivial. Also, the bin scripts could be
>> cleaned up significantly (which they need to be IMO).
>> I would love to hear what everyone thinks of this. Am I crazy? Is SBT
>> really better? Convince me!
>> -David