Hi Matt.

As a guy who invented and started this whole iTest thing let me put it
blindly: iTest cares no
less about particular build system of a project it is trying to test
as far as produced artifacts are reasonably managed.

The whole Gradle idea is _completely_ great. Here're the reasons:
  - programming in XML sucks. For real. If you need to describe
dependency using XML - sure, why not. Once you need to do something
beyond that or more than Maven has been created to do - you literally
has no choice there. That's why nice people in Maven community had to
add an ability to in-line Groovy scripts into poms: because Maven is a
very rigid build system. I don't want to start any flame throwing, but
there are things Maven is good for and things it isn't suitable.
Having custom logic in the build without creating 3215th plugin is one
of the latter.
  - having a better way of creating integration test artifacts and a
flexible entry point into their execution is a very smart move. I wish
I wasn't lazy and looked at it in the earlier stage of iTest...
  - iTest was/is successfully working with 0.20.203+, 0.22, and 0.23
and everyone of these has its own build systems, which are really very
different.

So, the answer to your question is no: Hadoop stack's component builds
will/should remain where Hadoop dev. community wants it to be.

BTW,
>> Groovy is much nicer to code than XML.
is a brilliant assertion: coding in the real dynamic OOP language is
much more pleasant than doing so in XML ;)
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

On Mon, Nov 7, 2011 at 13:24, Matt Foley <[email protected]> wrote:
> Looking at Gradle, I found this disconcerting statement (
> http://stackoverflow.com/questions/1163173/why-use-gradle-instead-of-ant-or-maven):
>
>> Groovy is much nicer to code than XML.
>
>
> Are you proposing that we manage the build system in Groovy?
> Unless the whole ecosystem can be moved in this direction, I would
> recommend against it.
>
> --Matt
>
> On Mon, Nov 7, 2011 at 11:57 AM, Tom White <[email protected]> wrote:
>
>> +1 to lowering the barrier to entry for contributing new tests (#7).
>>
>> Also, rather than introduce a new build system, why not improve the
>> plugin (failsafe) if it has deficiencies?
>>
>> Tom
>>
>> On Fri, Nov 4, 2011 at 4:00 PM, Roman Shaposhnik <[email protected]> wrote:
>> > Folks,
>> >
>> > one of the biggest challenges that I'd like to tackle post Bigtop
>> > 0.2.0 is increasing
>> > the scope, coverage and robustness of the iTest and its test artifacts.
>> To that
>> > end I've started a Wiki page outlining the issues:
>> >    https://cwiki.apache.org/confluence/display/BIGTOP/iTest.next
>> >
>> > Feel free to contribute and I really hope we can spend some time at
>> ApacheCON
>> > talking about that.
>> >
>> > Thanks,
>> > Roman.
>> >
>>
>

Reply via email to