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]> 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
