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.
-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
>
--
View this message in context:
http://old.nabble.com/How-to-define-custom-remote-repo-for-client-dependency--tp27255683p27307958.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
