Maven (was: Hardcoded paths in examples)

[Karl Wettin <ka...@gmail.com>]

This is only in response to the Maven parts, I'll have to respond to  
the rest a bit later.

Remember that the Maven support is something secondary.

We already require people to get our distribution and execute "mvn  
install" in order to install all those dependecies that isn't  
distributed via Maven central (Hadoop & co), or manually install the  
dependencies to their local repository.

As it's already sort of messed up I'm OK with that fact that passing  
Maven tests depends on first executing the Ant tests.

People in Maven fora recommends that we upload all the artifacts to  
central, but I think there might be political problems with that. It  
wouldn't be a license problem though. Perhaps

Also, although the package target now depends on Maven to produce  
artifacts I don't think it should have to do that in the future.


22 sep 2008 kl. 11.47 skrev Sean Owen:

> 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 <ka...@gmail.com>  
> 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 <a_...@yahoo.fr> 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 <sr...@gmail.com> a  
>>>> écrit :
>>>>
>>>>> De: Sean Owen <sr...@gmail.com>
>>>>> 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 <ka...@gmail.com>
>>>>> 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
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>