> From that perspective, I guess I think it's suboptimal
> to depend on Hadoop Path objects here in the unit test, since the tests
> are not actually using Hadoop. That ought to be separated.
But even if the test code is not using Hadoop, it's still calling Hadoop code :
Mappers, Reducers and all the happy family :)
> Then you have test code depending on external scripts -- in
> two places. Which would lead me to the conclusion that it's
> best, overall, if these tests are self-contained and cause their
> dependent data to be generated. I am not familiar with this code. Is
> that easy? infeasible?
It's feasible...but not easy :(
--- En date de : Lun 22.9.08, Sean Owen <[EMAIL PROTECTED]> a écrit :
> De: Sean Owen <[EMAIL PROTECTED]>
> Objet: Re: Hardcoded paths in examples
> À: mahout-dev@lucene.apache.org
> Date: Lundi 22 Septembre 2008, 11h47
> I don't think that is necessary. I think it is fair to
> assume that one
> is running the tests from within the distribution directory
> and not
> have to resort to that abstraction.
>
> From that perspective, I guess I think it's suboptimal
> to depend on
> Hadoop Path objects here in the unit test, since the tests
> are not
> actually using Hadoop. That ought to be separated.
>
> But that aside, that still leaves the issue of whether one
> can depend
> on some build products existing in a test. I don't
> think it's a bad
> thing, as long as the Ant script ensures those build
> products exist.
> Then the question is, can you express the same dependency
> in Maven? I
> think you can?
>
> Then you have test code depending on external scripts -- in
> two
> places. Which would lead me to the conclusion that it's
> best, overall,
> if these tests are self-contained and cause their dependent
> data to be
> generated. I am not familiar with this code. Is that easy?
> infeasible?
>
> Sean
>
> On Mon, Sep 22, 2008 at 9:59 AM, Karl Wettin
> <[EMAIL PROTECTED]> wrote:
> > Hmm, if this is test/resources, shouldn't they be
> accessed using
> > getResourceAsStream instead? I'll see what I can
> do.
> >
> > 22 sep 2008 kl. 10.15 skrev Sean Owen:
> >
> >> Oh OK. Well +1 to using the same path, yes. If it
> is easier to adapt
> >> to Maven's location, OK.
> >>
> >> On 9/22/08, deneche abdelhakim
> <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> Dumb question: why does example code
> depend on test code?
> >>>> Can this be solved by severing that
> dependency?
> >>>
> >>> It's not from the example code but from
> the example's test code. In this
> >>> case the example's tries to access a
> directory (wdbc) put into
> >>> test/resources. The content of test/resources
> is automatically copied by
> >>> ant
> >>> into build/test-classes/
> >>>
> >>>
> >>>> That means that the maven test builds will
> fail unless
> >>>> the ant test was first executed. I suppose
> that's OK, but
> >>>> I'd prefere if we could come up with
> some fix. I suppose the simplest
> >>>> one
> >>>> would be to use the maven file paths
> (target/test-classes).
> >>>
> >>> But in this case, the ant test builds will
> probably fail unless the maven
> >>> test was first executed ! Why not use the same
> file path for both ant and
> >>> maven, or at least copy the content of the
> ressources in a common
> >>> directory...
> >>>
> >>> --- En date de : Dim 21.9.08, Sean Owen
> <[EMAIL PROTECTED]> a écrit :
> >>>
> >>>> De: Sean Owen <[EMAIL PROTECTED]>
> >>>> Objet: Re: Hardcoded paths in examples
> >>>> À: mahout-dev@lucene.apache.org
> >>>> Date: Dimanche 21 Septembre 2008, 18h07
> >>>> Dumb question: why does example code
> depend on test code?
> >>>> Can this be
> >>>> solved by severing that dependency?
> >>>>
> >>>> On 9/21/08, Karl Wettin
> <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>>
> >>>>> There are a bunch of hardcoded paths
> in the tests of
> >>>>
> >>>> the examples
> >>>>>
> >>>>> module. Stuff like this:
> >>>>>
> >>>>> Path inpath = new
> >>>>
> >>>> Path("build/test-classes/wdbc");
> >>>>>
> >>>>> That means that the maven test builds
> will fail unless
> >>>>
> >>>> the ant test
> >>>>>
> >>>>> was first executed. I suppose
> that's OK, but
> >>>>
> >>>> I'd prefere if we could
> >>>>>
> >>>>> come up with some fix. I suppose the
> simplest one
> >>>>
> >>>> would be to use the
> >>>>>
> >>>>> maven file paths
> (target/test-classes).
> >>>>>
> >>>>>
> >>>>> karl
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
> >
