Bill,
The fact that some libraries don't put the version number in their jar file
name can indeed be solved by addArtificatPattern.
But the fact that you keep the version number of the library in the
directory structure causes other issues.
When you have a first level dependency that has transitive dependencies you
need to know the version number of your first level dependency in the
pattern of your transitive dependencies. I'm not sure but I don't think this
can be achieved because dependencies are always references to the library in
the repository itself an are never found below another library.
Also imagine you have 2 libraries A and B you are depending on with a
transitive dependency on the library C but different versions neither of the
2 libraries (A and B) include the version number in their transitive
dependencies on C. In this situation you really don't know what version
you'll get. It is possible that you already have this problem or even worse
get multiple versions of the same library (because you use the *.jar file
specification).
So because of the directory structure and the *.jar file specification you
are having a rather complex set of issues that are not easily solved.
The current directory structure also prevents you from using clientModules
in a useful way (transitive dependencies are located below the library
version path - can't handle this automatically).
But nevertheless clientModules can still be of use. I don't recommend using
clientModules this way because it totally ignores the reason they exist.
dependencies {
// manual - if you don't need every jar file from a directory you can use
this method
clientModule(['compile'], ":jibx:1.1.6") {
setArtifacts([
new Artifact('jibx-run','jar','jar','jibx-run',
'file:'+rootDir.absolutePath+'/java-libs/jibx/jibx-1.1.6/lib/jibx-run.jar'),
new Artifact('jibx-bind','jar','jar','jibx-bind',
'file:'+rootDir.absolutePath+'/java-libs/jibx/jibx-1.1.6/lib/jibx-bind.jar')
])
}
// with function - if you need all jar files
clientModule(['compile'], ':hibernate:???') {
setArtifacts(getArtifiacts([new File(javaLibsDir,
'/hibernate/hibernate-???'), new File(javaLibsDir,
'hibernate/hibernate-???/libs')))
}
}
List<Artifact> getArtifacts(File[] directories]) {
// find all jar files in directories
}
of course you can make the getArtifacts function as complex as you need (
add functionality to do excludes/includes for more fine grained control over
the jars that get included).
I do hope that you have some view on your transitive dependencies if not you
may want to put in the additional effort to use the flat directory resolver
or a maven style directory structure and use clientModules with dependencies
instead of hard code the artifacts.
Kr,
Tom
2008/12/30 wpfeiffe <[email protected]>
>
> I am investigating converting our j2ee EAR build from ant to gradle. Our
> ear
> contains 4 main artifacts (a utility jar, a war and 2 ejb jars). We don't
> use IVY or Maven. We keep our library dependencies in a separate directory
> structure that has the following format:
>
> \java-libs\<libname>\<libname-version>\<original lib dist structure>
>
> examples:
>
> \java-libs\jakarta-oro\jakarta-oro-2.0.8\<original lib dist for oro 2.0.8>
> \java-libs\jibx\jibx-1.1.3\<original lib dist for jibx 1.1.3>
>
> Note that the <original lib dist structure> represents the structure that
> library zip file contained when unzipped to its versioned directory.
>
> A quick count shows that we have 44 library distribution dependancies
>
> The issues I am encountering are:
>
> 1. Some distributions do not version name their jars and I don't like the
> ideas of mucking with the original distributions to rename them. (We keep
> the version name ourselves in the directory structure)
> 2. Our ant build often pulls in all dependant jars within a library
> distribution with a *.jar file specification
>
> It sounds like gradle MAY offer some kind of solution for issue #1 with the
> addArtifactPattern if it can address the full path and not just the file
> name of the artifact.
>
> It looks like issue #2 could be addressed with Client Modules but again, I
> may have library distributions that provide dependant jars that don't
> contain versioning within their names. This may be my problem to contend
> with but for me its a massive one. It means that I have to build the
> depandancies for all 44 distributions. Some may contain few or none, but
> some do contain MANY (hibernate, spring, etc)
>
> Any thoughts on how to approach my 2 issues?
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/dependancy-on-legacy-library-distributions-tp21216605p21216605.html
> Sent from the gradle-user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
