Dependencies in Maven

[pwgit-create]

Dependency vs Plugin

When working with Maven projects, you might encounter dependencies defined both directly within
<dependencies> tags and within plugins (like build plugins) in pom.xml. There are important differences
between these two approaches:

1. Scope of Dependencies:

   • Within <dependencies> tags: These dependencies are typically project dependencies that your application
     code will use at runtime or compile time. They can be used by the main classes and other modules of your project.
   • Within a plugin configuration: These dependencies are generally only needed for the build process itself
     (compilation, testing, packaging, etc.). They won't be available to your application's runtime classpath unless
     you explicitly configure them to be.

2. Classpath Usage:

   • <dependencies>: These are added to the project's compile and runtime classpath.
   • Plugin dependencies: By default, these are not added to the main project's classpath; they're only used
     by the plugin during the build process.

3. Transitive Dependencies:

   • <dependencies>: Maven will resolve transitive dependencies for you when you declare them in this
     section.
   • Plugin dependencies: Similar to the <dependencies>, Maven will also manage transitive dependencies, but
     these are again scoped only to the plugin's execution context.

4. Lifecycle Phases:

   • <dependencies>: These are available throughout all phases of the build lifecycle (compile, test,
     package, install, deploy).
   • Plugin dependencies: These dependencies are only available during the specific phase or goal that they
     are configured for in a plugin.

5. Examples:

   <!-- Project dependency -->
   <dependencies>
       <dependency>
           <groupId>com.example</groupId>
           <artifactId>example-library</artifactId>
           <version>1.0.0</version>
       </dependency>
   </dependencies>
   
   <!-- Build plugin with its own dependencies -->
   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-compiler-plugin</artifactId>
               <version>3.8.1</version>
               <dependencies>
                   <dependency>
                       <groupId>com.example</groupId>
                       <artifactId>plugin-helper</artifactId>
                       <version>1.0.0</version>
                   </dependency>
               </dependencies>
           </plugin>
       </plugins>
   </build>

6. Best Practices:

   • Only declare dependencies in the plugin section if they are specifically needed by that plugin during the
     build process.
   • If a dependency is required by your application code, it should be declared within the <dependencies> tag.

---

When a plugin dependency is added to the artifact jar.

When you configure a plugin like the maven-javadoc-plugin in your build section, it's primarily intended to be
used during the build process. However, its output (the generated Javadocs) can be included in the final artifact
or deployed separately based on how you've set up the plugin and its goals.

Here’s why this happens:

1. Plugin Execution: When you define a plugin with specific goals, Maven executes those goals at the
   appropriate phase of the build lifecycle. For example:

   <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-javadoc-plugin</artifactId>
       <version>3.4.0</version>
       <executions>
           <execution>
               <id>attach-javadocs</id>
               <phase>package</phase>
               <goals>
                   <goal>jar</goal>
               </goals>
           </execution>
       </executions>
   </plugin>

   In this configuration, the maven-javadoc-plugin is set to run during the package phase of the build. The
   goal jar generates a JAR file containing the Javadocs.

2. Attach Artifact: When you use the jar goal with the JavaDoc plugin, it not only generates the Javadocs
   but also attaches them as an additional artifact to the project's build lifecycle. This means that Maven will
   package these Javadocs into a separate JAR file and include it in the build output.

3. Inclusion in Repository: When you deploy your artifacts (e.g., to GitHub Packages or another repository),
   this attached Javadoc JAR gets included as part of the deployment process, alongside your main JAR artifact.

4. Classpath Independence: Even though the JavaDoc plugin dependencies are only needed for generating the
   documentation and not for running the application, their output (the generated Javadocs) can still be packaged and
   deployed separately.

So to summarize:

• The JavaDocs being included in the compiled JAR is due to the specific goals configured for the
  maven-javadoc-plugin.
• These goals generate the Javadocs and attach them as a separate artifact during the build process.
• This attached artifact gets deployed along with your main application JAR, making it available on GitHub
  Packages or other repositories.

If you look at the Maven documentation or your specific plugin configuration, you'll see that the jar goal is
responsible for creating this separate Javadoc JAR file:

<goal>jar</goal>

This is what allows the generated JavaDocs to be included in the deployment output.