What you probably want is below:
dependency(':apache-river:2.1.1') {
artifact { name='jsk-platform' ; type='jar' }
artifact { name='jsk-lib' ; type='jar' }
}
Gradle does not keep it's mapping based upon artifacts but rather at the
module level. If you have jsk-platform and jsk-lib treated as modules (like
maven does), then you just have apache-river as the organization/group and
you are fine.
We have our stuff sorted by the publishing organization, module, and
specific artifacts:
dependency('com.sun:javamail:1.4.1') {
artifact { name = 'mailapi' ; type = 'jar' }
}
dependency('com.oracle:jdbc:10.20.0.1.0') {
artifact { name = 'ojdbc14' ; type = 'jar' }
}
Oracle ships with a whole bunch of jdbc drivers, and the ojdbc14 is an older
version driver needed for some software.
We could have done
dependency 'javamail:mailapi:1.4.1'
or
dependency 'com.sun:mailapi:1.4.1'
but both technically lose a little bit of information, as javamail isn't
really a group, and mailapi is just one jar artifact of the javamail module.
Like I said, using artifacts with gradle is nowhere near as simple as
treating each artifact as a "module".
When the module and the specific artifact needed from the module have the
same name, you can still use the shorthand
dependency 'org.apache:log4j:1.2.8'
and get the log4j.jar file as expected.
-Spencer
tinca wrote:
>
> Hi,
>
> A freshly starting build (.gradle removed, gradle clean called) downloads
> some of a client module dependencies, but does not others (not even
> resolving is attempted). The compile step then fails not founding classes.
> If after this, all dependencies are uncommented except the missing one,
> this missing one is downloaded, too (of course the compilation fails,
> because now the others are not on the classpath).
> Enabling all the dependencies restores the original state: the jar that
> was missing is absent again from the classpath, compilation fails.
>
> A custom repo is used with no descriptors.
>
> This is the problematic definition couple, that is part of a client module
> dependency definition:
>
> dependency(':apache-river:2.1.1') {
> artifact { name='jsk-platform' ; type='jar' }
> }
> dependency(':apache-river:2.1.1') {
> artifact { name='jsk-lib' ; type='jar'
> }
>
> I observed that the last one is ignored (changing their order clearly
> shows it).
> I would consider it a bug. I see no easy workaround, putting all the jars
> into different dirs tedious (there are many jars under this package).
>
> Any other idea would be welcome!
> Zsolt
>
> Ps. Perhaps I should use a repo structure which more of Maven-like,
> because the current layout is somewhat ad-hoc:
> [module]/[revision]/artifacts...?
>
>
>
--
View this message in context:
http://old.nabble.com/partially-handled-client-module-dependencies-tp27335632p27348068.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
