Spencer,
thank you for your sugestion. I think it was one of test I have done, but I
will try it again.
Now, I am using the following
repositories {
add( new org.apache.ivy.plugins.resolver.FileSystemResolver()) {
name = 'lib'
addArtifactPattern
"$projectDir/lib/[module](-[revision])(-[classifier]).[ext]"
addArtifactPattern "$projectDir/lib/[module].[ext]"
descriptor = 'optional'
checkmodified = true
}
}
I will try to replace it with
repositories
{
flatDir name: 'localRepository', dirs: project.projectDir.path
libDir = project.projectDir.path + '/lib'
localRepository.setArtifactPatterns([libDir + '/[artifact].[ext]'])
localRepository.addArtifactPatterns([libDir +
'/[module](-[revision])(-[classifier]).[ext]) // I need also this
}
Ciao
Walter
On 20 May 2010 19:38, Spencer Allain <[email protected]> wrote:
> I used to have a similar extraneous dash/"-" problem when war files were
> constructed using externally resolved dependencies, those jar files were
> stuff into the internal gradle cache with xyz-.jar. (It was fixed last
> November I believe)
>
> I'm guessing there is some other place still within the gradle code that is
> always assuming there will be a version number and optimistically putting
> the dash into the name.
>
> Would the below code be what you really want to do as much of the resolve
> stuff was moved into repositories:
>
> repositories
> {
> flatDir name: 'localRepository', dirs: project.projectDir.path
>
> // NOTE: Get a GStringImpl cannot be cast to java.lang.String issue
> // when using "$project.projectDir.path....." directly in pattern
> libDir = project.projectDir.path + '/lib'
>
> // NOTE: This removes the default constructed pattern
> localRepository.setArtifactPatterns([libDir + '/[artifact].[ext]'])
> }
>
> dependencies
> {
> compile ':SNMP4J'
> //compile ':snm...@jar'
> //compile 'SNMP4J:snm...@jar'
> //compile 'SNMP4J:SNMP4J'
>
> // NOTE: If you are just grabbing jars from a directly without any
> ivy/pom files, then
> // the first form is probably what you want (use @jar
> otherwise)
> }
>
> -Spencer
>
> --- On *Thu, 5/20/10, Walter Di Carlo <[email protected]>* wrote:
>
>
> From: Walter Di Carlo <[email protected]>
> Subject: Re: [gradle-user] Issue with the name of cached dependency
> artifacts
>
> To: [email protected]
> Date: Thursday, May 20, 2010, 9:08 AM
>
>
> 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]<http://mc/[email protected]>
> > wrote:
>
>>
>>
>> On 19 May 2010 21:33, Steve Appling
>> <[email protected]<http://mc/[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]<http://mc/[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
>>
>
>
>
