Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> 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.

-David

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
>>
>>
>>
 
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB