Rene,
sorry if I haven't answered before. I was not aware that gmail does
not put a replied email into the inbox :(
Thank you very much for your suggestion. I will try it as soon as
possible. Unfortunately I am not full time on Gradle.
Note that such piece of code was under the tag subprojects { } and my
workspace is organized as flat list of folders, i.e.
prj1
prj2
gradle
prj3
...
I start gradle from within the gradle folder and everything seems to work.
Walter
On 6 July 2010 13:21, Rene Groeschke <[email protected]> wrote:
> Hi Walter,
> no problem. at least we discovered a potential issue with mixing test and
> operational code. One tiny advice for your setup: you should replace this
>
> sourceSets.main.classesDir = new File('build/bin') by
> sourceSets.main.classesDir = file('build/bin')
>
> to make sure your source set is always in build/bin relative to project
> directory and not relative to the path you start your gradle build from.
>
> regards,
> René
>
>
> Am Di, 6.07.2010, 10:50, schrieb Walter Di Carlo:
>> It was my fault :( During the migration of my script I forgot to
>> change the source location for the tests. Now, I have adopted the following
>>
>>
>> sourceSets.main.classesDir = new File('build/bin')
>> sourceSets.main.java.srcDir 'src' sourceSets.main.resources.srcDir 'src'
>> sourceSets.test.resources.srcDir 'test'
>>
>> and everything seems to work.
>>
>> Sorry, for the time spent to investigate such silly case.
>>
>>
>> Thank you for all your support.
>>
>>
>> Ciao
>>
>>
>> Walter
>>
>>
>> On 28 June 2010 18:03, Rene Groeschke <[email protected]> wrote:
>>
>>> I totally agree,
>>> I just wanted to point out, that the fix for GRADLE-825 only checked
>>> that no duplicate src entry is created if resource and source directory
>>> point to the same directory. If someone wants his tests sources in the
>>> same sourceset as productive code gradle and the eclipse plugin should
>>> support this. a corrupt .classpath file as output is always a bug i
>>> think.
>>>
>>> regards, René
>>>
>>>
>>> Am Mo, 28.06.2010, 17:10, schrieb John Murph:
>>>
>>>> While I agree with René that usually the unit tests are not in the
>>>> same directory as production code, Gradle doesn't generally require
>>>> this. I'll speak for Hans here (he can slap me down if I'm wrong!):
>>>> Gradle does not
>>>> wish to impose any such view upon a project. If a project wants to
>>>> put it's unit tests in the same directory as it's production code,
>>>> Gradle
>>>> should support this (it might require a bit more configuration that
>>>> normal, however). The problem is that the Eclipse project generation
>>>> is just not fully mature yet. I believe Hans is planning to work on a
>>>> new Eclipse
>>>> project generation plugin along the lines of the new IDEA project
>>>> generation plugin. That effort should make cases like this
>>>> straightforward to declare.
>>>>
>>>> Now Hans can step in and "correct" me where I'm wrong. :)
>>>>
>>>>
>>>>
>>>> On Mon, Jun 28, 2010 at 6:28 AM, Rene Groeschke <[email protected]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Hi Walter,
>>>>> it seems that you mix your test code with your productive code.
>>>>> Gradle-825
>>>>> just fixes a mix of resource files and source code.
>>>>>
>>>>> Normally your unit tests shouldn't be in the same directory as your
>>>>> productive code.
>>>>>
>>>>> regards, René
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> John Murph
>>>> Automated Logic Research Team
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
