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?
I think the biggest problem is that there isn't clear ownership of the
build stuff we have. SBT is probably fine if you know it well. Ant and
maven are probably the same. The problem is that none of the
committers seem to know SBT well that that is a big barrier for
getting basic stuff like a good unit test report, etc.

My personal preference would be for Maven followed by Ant followed by
anything else (including SBT), but I think the ownership maintenance
issue is more important than the framework.

The two useful things that SBT bought us where compile targets (i.e.
scala 2.8 vs 2.9) and incremental compilation. I think both are
available outside sbt now...?

-Jay
On Mon, Apr 8, 2013 at 12:52 PM, David Arthur <[EMAIL PROTECTED]> wrote:
> 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