I have found a solution, but I think it is not the best way to do it
Now, I use the follwoing code for each sub-project containing a dependency
from a jar without the version in its name
============================================================================
myclosure = { project.projectDir.path+'/lib/'+ it }
jars_array = [ "SNMP4J.jar" ].collect( myclosure )
dependencies {
compile "slf4j-api:slf4j-api:1.5.8"
compile files( jars_array ) // this replace compile "SNMP4J:SNMP4J:jar"
runtime "logback-core:logback-core:0.9.17",\
"logback-classic:logback-classic:0.9.17"
}
============================================================================
Before I was not having such king of problems because I could use something
like the following
dependencies {
getBuildResolver().addArtifactPattern('$projectDir.path/[artifact].[ext]')
addFlatDirResolver('mylib',
projectDir.path+'/lib').addArtifactPattern(projectDir.path+'/lib/[artifact].[ext]')
testCompile('junit:junit:4.4')
}
So, the question is: now, with 0.9+, can I use something like that?
Regards,
Walter
On 20 May 2010 11:12, Walter Di Carlo <[email protected]> wrote:
>
>
> On 19 May 2010 21:33, Steve Appling <[email protected]> wrote:
>
>>
>> On May 19, 2010, at 10:50 AM, Walter Di Carlo wrote:
>>
>>
>>
>> On 19 May 2010 16:31, Spencer Allain <[email protected]> wrote:
>>
>>> compile "myjar:myjar:jar"
>>> says that you want organization "myjar", module "myjar" and revision
>>> "jar" (and since it's a compile dependency, it automatically assumes "jar"
>>> as the extension)
>>>
>>> I assume you really want either:
>>>
>>> compile "myjar:myjar"
>>> or
>>> compile "myjar:my...@jar"
>>>
>>> affected by needs of raw artifact versus potential transitive
>>> dependencies.
>>>
>>
>> Thank you for your suggenstion.
>>
>> I have played with such examples, but in both cases I am getting a jar
>> with filename myjar-.jar containing a wrong dash
>>
>> As workaround I will try to copy the jars directly from the lib folders of
>> the projects
>>
>>
>>
>> I think you really do have the revision set wrong. It's possible that
>> when you re-ran your build to try these suggestions, the jar step was
>> optimized out since your source didn't change. You might try retesting with
>> the --no-opt option. It sounds like you are having problems with the
>> filename of your own jars (from a different subproject), not the name of
>> external dependencies.
>>
>
> No, I have the problem with just the external dependencies not having the
> version number in their names. It was not a good idea to call it myjar.jar
> :( Sorry, for that
>
>
>
>> In that case, it would be typical that you would refer to them with a
>> project dependency like "compile project('projb')" and not "compile
>> 'myproj:projb'". Did you set project.version in each project?
>>
>
> Yes, I am using it and it is working correctly.
>
>
>>
>> Also, if you are only trying to copy out the jars, then the bulk of your
>> CopySpec is not needed - you don't need the first from and all the excludes.
>>
>
> I am trying to create a package ready for distribution. So, such package
> must contains everything is needed to run the application not only the jars.
>
>
> Anyway, thank you for your suggestions.
>
> As last test, I will try to apply my build.gradle to a simplified
> multi-project workspace to see if the problem is in my workspace or in the
> gradle/ivy side.
>
> Ciao
> Walter
>
