การประกาศการพึ่งพาของโครงการ

Modern software projects rarely work in isolation. They often rely on external code, known as dependencies, to perform various tasks.

Think of dependencies as pre-built tools or libraries that save you from writing common functionalities from scratch, like logging, parsing JSON, or connecting to a database.

• Libraries: Collections of code (e.g., Apache Commons).
• Frameworks: Structured foundations for applications (e.g., Spring Boot).
• Modules: Components of a larger system.

In Gradle, you declare all your project's dependencies within a dedicated dependencies { ... } block in your build.gradle file.

This block is central to managing what your project needs to compile, test, and run.

Before Gradle can fetch dependencies, it needs to know where to look. This is defined in the repositories { ... } block.

The most common repository is Maven Central, a vast public repository for Java libraries. By declaring mavenCentral(), you tell Gradle to search there.

The implementation configuration is your go-to for most production dependencies. It adds the dependency to the compilation classpath and also to the runtime classpath.

Crucially, implementation dependencies are not exposed to other modules that consume your project, which helps with faster compilation and better encapsulation.

Let's see a simple Java class that uses a library added with implementation. We'll add the Apache Commons Lang library for string utilities.

Dependencies needed only for running tests (like JUnit 5 or Mockito) should be declared with testImplementation.

These dependencies are added to the test compilation and runtime classpaths but are not included in your final application artifact or exposed to production code.

Sometimes, a dependency is only needed when your application actually runs, not during compilation. This is where runtimeOnly comes in.

A common use case is a JDBC driver. Your code compiles against the JDBC API (which is often part of Java or a compileOnly dependency), but the specific driver (e.g., HSQLDB, PostgreSQL) is only needed at runtime.

Use compileOnly for dependencies that are required during compilation but should not be packaged with your final application or available at runtime.

Examples include annotation processors like Lombok, or API specifications (e.g., Servlet API) when your application will run in an environment that already provides them.

While generally discouraged, you might sometimes need to include a local JAR file that isn't available in any public repository (e.g., a proprietary library).

You can declare these using the files() method within the dependencies block. Make sure the path is correct relative to your project root.

You are building a web application and need to include:

• A logging library for all code.
• JUnit 5 for unit tests.
• The Servlet API, which your application server already provides.

Which Gradle dependency configurations would you use for these three items?

Great job! You've learned the essentials of declaring dependencies in Gradle:

• The dependencies { ... } block is where you list all external libraries.
• repositories { ... } tells Gradle where to find these libraries (e.g., mavenCentral()).
• implementation for most production code.
• testImplementation for test-specific libraries.
• runtimeOnly for dependencies only needed at runtime.
• compileOnly for compile-time only dependencies not packaged.
• You can also include local JARs using files().

Understanding these configurations helps you build efficient and well-structured projects!