>Well, I guess gradle simply does not support to reference several artifacts
for the same project with different classifiers within the same
configuration.
>This works only well as long as I do not try to access resources from the
main jar from within the unit tests.
That's strange... Given that both jars (main & testsupport) are resolvable
Gradle should be able to build. At least it builds ok for me :) Can you
double check both jars are located in your local repo or gradle cache?
Nevertheless I think that eclipse .classpath generation misbehaves and adds
only one dependency instead of two. Can you file a jira ticket?
Cheers!
Szczepan
I think you're right I was able . It seems it is a problem with an eclipse
plugin
On Mon, Mar 14, 2011 at 4:21 PM, Thomas Thevis <thevis...@googlemail.com>wrote:
> Hello Szczepan,
>
> I have to correct my initial statement:
>
> > dependencies {
> > compile 'my.group:baseproject:1.0'
> > testCompile 'my.group:baseproject:1.0:testsupport'
> > }
> >
> > This works well for plain gradle tasks. I can compile both main and
> > test classes. Tests can be run without problems.
>
> This works only well as long as I do not try to access resources from the
> main jar from within the unit tests.
>
> Well, I guess gradle simply does not support to reference several artifacts
> for the same project with different classifiers within the same
> configuration.
>
>
> > Do you mean that in your case the .classpath content depends on the
> > order of entries in dependencies { } ?
> Yes. My eclipse classpath contains all the libs which are referenced from
> the 'testCompile' configuration. Based on the first guess from above, I
> assume that only one of the two candidate artifacts will make it to the
> final dependency list and which one seems to depend on the order of
> declaration within the dependencies {} block.
>
> Therefore, I ended up putting the test support related code into its own
> package within the main jar. The main disadvantage is that I had to promote
> some dependencies from 'testCompile' to 'compile' configuration which is
> obviously kind of bad for a base project.
> If anyone has a better idea, please let me know.
>
> Thanks,
> Thomas
>
>
> Am 14.03.2011 15:44, schrieb szczepiq:
>
>> Hello,
>>
>> >However, the eclipse plugin does not add both jars as libs to the
>> classpath entries. Instead, only the one which comes last in the
>> dependencies configuration is added.
>>
>> Do you mean that in your case the .classpath content depends on the
>> order of entries in dependencies { } ?
>>
>> Can you check if both jars (the main & testsupport) are in .gradle
>> caches or the local maven repo?
>>
>> I couldn't reproduce this issue. Given both jars are resolvable then
>> .classpath was created with both entries. Interestingly, if the
>> 'classified' jar was not resolvable then gradle eclipse executed OK,
>> however it crated .classpath without the 'classified' jar.
>>
>> Hope that helps!
>> Szczepan
>>
>> On Sun, Mar 13, 2011 at 2:09 PM, Thomas Thevis <thevis.ml
>> <http://thevis.ml>@googlemail.com <http://googlemail.com>> wrote:
>>
>> Hello all,
>>
>> for a base java project consisting mainly of interfaces and abstract
>> classes I created both a baseproject-1.0.jar and a
>> baseproject-1.0-testsupport.jar which is made up of mock
>> implementations and intended to be used for unit tests.
>> In another project I want to declare dependencies as follows:
>>
>> dependencies {
>> compile 'my.group:baseproject:1.0'
>> testCompile 'my.group:baseproject:1.0:testsupport'
>> }
>>
>> This works well for plain gradle tasks. I can compile both main and
>> test classes. Tests can be run without problems.
>> However, the eclipse plugin does not add both jars as libs to the
>> classpath entries. Instead, only the one which comes last in the
>> dependencies configuration is added.
>>
>> Is this a bug in the eclipse plugin or am I using it the wrong way?
>> If it is a bug, does anyone know a workaround?
>>
>> BTW: I'm using gradle-0.9.1 and gradle-1.0-milestone-1.
>>
>> Thanks for any help!
>> Thomas
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
