You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@crunch.apache.org by Matthias Friedrich <ma...@mafr.de> on 2013/03/27 11:38:27 UTC
The future of crunch-test
Hi,
I think the reason why we created crunch-test originally was that
someone (probably Josh ;-)) needed the TemporaryPath class for some
other project. We recently managed to get this into MRUnit
[MRUNIT-162], so this reason no longer exists. Also, JUnit 4.11
fixed some Scala-related problem with the @Rule mechanism, so another
workaround is no longer needed.
I've never been happy with crunch-test - we're not in the business
of building test frameworks that aren't really related to Crunch
(remember, crunch depends on crunch-test, not the other way round)
and its dependencies caused us a lot of licensing trouble with the
binary distribution.
If we dropped crunch-test after MRUnit 1.1 is released, we could
get rid of 6 individual licenses (junit, hamcrest-core, mockito-all,
which includes cglib, asm, and objenesis), 5 of which aren't Apache
licensed and one even requires a NOTICE entry. I might even throw in a
test suite refactoring to get rid of our Project Gutenberg, err,
dependency ;-)
What do you think?
Regards,
Matthias
[MRUNIT-162] https://issues.apache.org/jira/browse/MRUNIT-162
Re: The future of crunch-test
Posted by Christian Tzolov <ch...@gmail.com>.
Because the MemPipeline is used mostly as a test stub it can be moved to
crunch-test. But this alone is not enough for keeping an extra project.
So +1 for discarding crunch-test in favour of MRUnit-1.1.
On Wed, Mar 27, 2013 at 3:58 PM, Brock Noland <br...@cloudera.com> wrote:
> Sounds good, from the MRUnit side, we'll try and get 1.1 out soon after
> 1.0.
>
>
> On Wed, Mar 27, 2013 at 9:55 AM, Josh Wills <jw...@cloudera.com> wrote:
>
> > Yep, pretty sure it was me. :) +1 for saying goodbye after the MRUnit
> > release.
> >
> > J
> >
> > On Wed, Mar 27, 2013 at 3:38 AM, Matthias Friedrich <ma...@mafr.de>
> wrote:
> > > Hi,
> > >
> > > I think the reason why we created crunch-test originally was that
> > > someone (probably Josh ;-)) needed the TemporaryPath class for some
> > > other project. We recently managed to get this into MRUnit
> > > [MRUNIT-162], so this reason no longer exists. Also, JUnit 4.11
> > > fixed some Scala-related problem with the @Rule mechanism, so another
> > > workaround is no longer needed.
> > >
> > > I've never been happy with crunch-test - we're not in the business
> > > of building test frameworks that aren't really related to Crunch
> > > (remember, crunch depends on crunch-test, not the other way round)
> > > and its dependencies caused us a lot of licensing trouble with the
> > > binary distribution.
> > >
> > > If we dropped crunch-test after MRUnit 1.1 is released, we could
> > > get rid of 6 individual licenses (junit, hamcrest-core, mockito-all,
> > > which includes cglib, asm, and objenesis), 5 of which aren't Apache
> > > licensed and one even requires a NOTICE entry. I might even throw in a
> > > test suite refactoring to get rid of our Project Gutenberg, err,
> > > dependency ;-)
> > >
> > > What do you think?
> > >
> > > Regards,
> > > Matthias
> > >
> > > [MRUNIT-162] https://issues.apache.org/jira/browse/MRUNIT-162
> >
> >
> >
> > --
> > Director of Data Science
> > Cloudera
> > Twitter: @josh_wills
> >
>
>
>
> --
> Apache MRUnit - Unit testing MapReduce -
> http://incubator.apache.org/mrunit/
>
Re: The future of crunch-test
Posted by Brock Noland <br...@cloudera.com>.
Sounds good, from the MRUnit side, we'll try and get 1.1 out soon after 1.0.
On Wed, Mar 27, 2013 at 9:55 AM, Josh Wills <jw...@cloudera.com> wrote:
> Yep, pretty sure it was me. :) +1 for saying goodbye after the MRUnit
> release.
>
> J
>
> On Wed, Mar 27, 2013 at 3:38 AM, Matthias Friedrich <ma...@mafr.de> wrote:
> > Hi,
> >
> > I think the reason why we created crunch-test originally was that
> > someone (probably Josh ;-)) needed the TemporaryPath class for some
> > other project. We recently managed to get this into MRUnit
> > [MRUNIT-162], so this reason no longer exists. Also, JUnit 4.11
> > fixed some Scala-related problem with the @Rule mechanism, so another
> > workaround is no longer needed.
> >
> > I've never been happy with crunch-test - we're not in the business
> > of building test frameworks that aren't really related to Crunch
> > (remember, crunch depends on crunch-test, not the other way round)
> > and its dependencies caused us a lot of licensing trouble with the
> > binary distribution.
> >
> > If we dropped crunch-test after MRUnit 1.1 is released, we could
> > get rid of 6 individual licenses (junit, hamcrest-core, mockito-all,
> > which includes cglib, asm, and objenesis), 5 of which aren't Apache
> > licensed and one even requires a NOTICE entry. I might even throw in a
> > test suite refactoring to get rid of our Project Gutenberg, err,
> > dependency ;-)
> >
> > What do you think?
> >
> > Regards,
> > Matthias
> >
> > [MRUNIT-162] https://issues.apache.org/jira/browse/MRUNIT-162
>
>
>
> --
> Director of Data Science
> Cloudera
> Twitter: @josh_wills
>
--
Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
Re: The future of crunch-test
Posted by Josh Wills <jw...@cloudera.com>.
Yep, pretty sure it was me. :) +1 for saying goodbye after the MRUnit release.
J
On Wed, Mar 27, 2013 at 3:38 AM, Matthias Friedrich <ma...@mafr.de> wrote:
> Hi,
>
> I think the reason why we created crunch-test originally was that
> someone (probably Josh ;-)) needed the TemporaryPath class for some
> other project. We recently managed to get this into MRUnit
> [MRUNIT-162], so this reason no longer exists. Also, JUnit 4.11
> fixed some Scala-related problem with the @Rule mechanism, so another
> workaround is no longer needed.
>
> I've never been happy with crunch-test - we're not in the business
> of building test frameworks that aren't really related to Crunch
> (remember, crunch depends on crunch-test, not the other way round)
> and its dependencies caused us a lot of licensing trouble with the
> binary distribution.
>
> If we dropped crunch-test after MRUnit 1.1 is released, we could
> get rid of 6 individual licenses (junit, hamcrest-core, mockito-all,
> which includes cglib, asm, and objenesis), 5 of which aren't Apache
> licensed and one even requires a NOTICE entry. I might even throw in a
> test suite refactoring to get rid of our Project Gutenberg, err,
> dependency ;-)
>
> What do you think?
>
> Regards,
> Matthias
>
> [MRUNIT-162] https://issues.apache.org/jira/browse/MRUNIT-162
--
Director of Data Science
Cloudera
Twitter: @josh_wills