On 11/11/2010, at 10:14 PM, richardm wrote:
>
> Hi,
>
> I have a lot of JAR files in lib directories which my projects depend on for
> their compile tasks. I have set my compile dependancies like this:
>
> dependencies {
> compile fileTree(dir: "$rootDir/../uwm/lib", include: '*.jar')
> }
>
> This works fine, but I wondered if I should be using a repository for my jar
> files with a flatDir instead of the compile dependancy (I'm not using Ivy or
> Maven) e.g.
>
> repositories {
> flatDir name: 'localRepository', dirs: 'lib'
> }
>
> What is the difference between these two approaches, I didn't really
> understand from the documentation. Is the repository approach the way to
> manage different jar versions, so you can specify a dependancy on a
> particular jar and version?
The basic difference is that with the first approach you declare nothing about
your dependencies, which means there's little Gradle can do to help you (and
others) understand and manage your dependencies. They're just an opaque set of
jars with no meaning to Gradle.
With the second approach, on the other hand, you explicitly declare each
dependency, along with why the dependency is required (eg to compile, to
execute, to test, etc). This means Gradle better understands your dependencies,
and can do things to help you. The cost is that you have to declare your
dependencies in the build script.
Neither approach is the 'right' approach. It depends on what you are building.
Personally, I would tend towards declaring my dependencies explicitly.
Some benefits of declaring your dependencies:
- it's easy to see the dependencies of your project
- Gradle can detect and help you manage conflicts in dependencies.
- you can publish your project along with only its runtime dependencies, rather
than all the stuff you need at test time.
- you can publish your project to a repository, along with its dependency
information, so that others can understand your dependencies, and do things
such as swap in different implementations of your dependencies when they
include your project.
- you can move your dependencies to a repository manager.
- you can publish your dependency information to your IDE, so that the IDE
knows what to use for production vs test code.
There are some things we'd like to do in Gradle in the future that would really
only work when you declare your dependencies:
- Reports and IDE integration to help you (and others) visualise your
dependency graph
- The ability to compare declared vs actual dependencies in the code, so you
can detect unused dependencies
- Dependencies on things other than pre-compiled jars. For example, we might
add source dependencies, where the dependency is built locally before being
used.
Of course, you may or may not care about any of these benefits for your
particular project.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
