On 26/01/10 1:20 AM, merscwog wrote:
So, to deal with artifact location issues I utilize a couple of IVY patterns:
'([organization]/)[module]/([revision]/)[type]s/[artifact](-[revision])(-[classifier]).[ext]'
'([organization]/)[module]/([revision]/)[type]s/[artifact](-[classifier]).[ext]'
'([organization]/)[module]/[type]s/[artifact](-[revision])(-[classifier]).[ext]'
The IVY tags within parens are optional (meaning they only get filled in if
they are provided by default).
Your directory structure has: groovy/1.6-RC-1/groovy-all-1.6-RC-1.jar
So, you are technically using [module] [artifact] and [revision] (although
gradle _really_ wants you to utilize [organization], [module] and
[revision])
Here, you'd utilize (notice that organization isn't being filled in, since
the ':' comes first):
dependencies {
compile(':groovy:1.6-RC-1') {
artifact { name='groovy-all' ; type='jar' }
}
}
Yes, you need to specify the explicit type for an artifact (and artifacts
are mostly hidden within gradle and there aren't many good examples of using
them). There is no "short-form" specification that utilizes artifact names.
Using the 3 patterns above this would look in:
groovy/1.6-RC-1/jars/groovy-all-1.6-RC-1.jar
groovy/1.6-RC-1/jars/groovy-all.jar
groovy/jars/groovy-all-1.6-RC-1.jar
Now, since you don't utilize the "jars" '[type]s' part of the pattern, this
would work fine for you:
'([organization]/)[module]/([revision]/)[artifact](-[revision])(-[classifier]).[ext]'
'([organization]/)[module]/([revision]/)[artifact](-[classifier]).[ext]'
'([organization]/)[module]/[artifact](-[revision])(-[classifier]).[ext]'
groovy/1.6-RC-1/groovy-all-1.6-RC-1.jar
groovy/1.6-RC-1/groovy-all.jar
groovy/groovy-all-1.6-RC-1.jar
You can utilize the recommended pattern, but that means "groovy" is the
organization, and "groovy-all" the module. Gradle contains all the
resolving power (and more) of IVY, but it tries hard to constrain its use to
Maven resolving patterns.
It's more that we haven't gotten around to making the ivy use cases
simpler. We certainly haven't tried to stop you using ivy. It is
possible to get at all the ivy capabilities if you want, but you have to
do it through the ivy APIs. But this is awkward compared to using a
maven style repo. In the Gradle 0.10 release, we are planing on making
this better.
For example, you might be able to specify the repository layout using a
closure instead of using an ivy pattern:
repositories {
local {
artifactLayout { artifact ->
"$libsDir/${artifact.name}-${artifact.version}.${artifact.extension}" }
}
}
The artifactLayout {} closure would be passed the Artifact object, and
could return anything that Gradle can resolve into a list of URLs: a
relative path, a URL, a File, a collection of these things, and so on.
Gradle would then download the artifacts from these URLs.
In the simple case, this is almost the same as using an ivy pattern.
But, the closure can do anything it likes: conditional statements, look
up things in a map or a database, download stuff, whatever. This gives
you a simple way to 'implement' a repository.
We might also have an 'ivy' plugin, which would add methods to the
repositories { } closure to let you use the ivy API directly to specify
your repositories (and probably add stuff to dependencies as well).
-Spencer
tinca wrote:
René Gröschke wrote:
Hi tinca,
I think the easiest way to get the groovy-all-1.6-RC-1.jar resolved in
your setup, is to add a second pattern like this:
http://our.www.server/librepo/[organisation]/[revision]/[module]-[revision].[ext]
this adds the revision to the jar file name.
This adds the revision to the jar file name. Now you should be able to
resolve groovy via groovy:groovy-all:1.6-RC-1
...
Hello René,
Yes, I can do it. What to do, however, when some of the jars has revision
info and some not at the same time? Is there a regexp-like feature for
defining that mix?
Nevertheless, it is not that big problem. If nothing else, when no
revision info is available an "unknown" revision tag can be used.
Thanks!
Zsolt
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
