Gradle java plugin sources

Gradle java plugin sources

A Plugin which compiles and tests Java source, and assembles it into a JAR file. This plugin creates a built-in test suite named test that represents the Test task for Java projects.

Field Summary

The name of the API configuration, where dependencies exported by a component at compile time should be declared.

The name of the configuration to define the API elements of a component that are required to compile a component, but not at runtime.

The name of the configuration that is used to declare dependencies which are only required to compile a component, but not at runtime.

The name of the implementation configuration, where dependencies that are only used internally by a component should be declared.

The name of the runtime classpath configuration, used by a component to query its own runtime classpath.

The name of the runtime elements configuration, that should be used by consumers to query the runtime dependencies of a component.

The name of the runtime only dependencies configuration, used to declare dependencies that should only be found at runtime.

The name of the configuration that should be used to declare dependencies which are only required to compile the tests, but not when running them.

Constructor Summary

Method Summary

Methods inherited from class java.lang.Object

Field Detail

PROCESS_RESOURCES_TASK_NAME

public static final java.lang.String PROCESS_RESOURCES_TASK_NAME

CLASSES_TASK_NAME

public static final java.lang.String CLASSES_TASK_NAME

COMPILE_JAVA_TASK_NAME

public static final java.lang.String COMPILE_JAVA_TASK_NAME

PROCESS_TEST_RESOURCES_TASK_NAME

public static final java.lang.String PROCESS_TEST_RESOURCES_TASK_NAME

TEST_CLASSES_TASK_NAME

public static final java.lang.String TEST_CLASSES_TASK_NAME

COMPILE_TEST_JAVA_TASK_NAME

public static final java.lang.String COMPILE_TEST_JAVA_TASK_NAME

TEST_TASK_NAME

public static final java.lang.String TEST_TASK_NAME

JAR_TASK_NAME

public static final java.lang.String JAR_TASK_NAME

JAVADOC_TASK_NAME

public static final java.lang.String JAVADOC_TASK_NAME

API_CONFIGURATION_NAME

public static final java.lang.String API_CONFIGURATION_NAME

The name of the API configuration, where dependencies exported by a component at compile time should be declared.

IMPLEMENTATION_CONFIGURATION_NAME

public static final java.lang.String IMPLEMENTATION_CONFIGURATION_NAME

The name of the implementation configuration, where dependencies that are only used internally by a component should be declared.

API_ELEMENTS_CONFIGURATION_NAME

public static final java.lang.String API_ELEMENTS_CONFIGURATION_NAME

The name of the configuration to define the API elements of a component. That is, the dependencies which are required to compile against that component.

COMPILE_ONLY_CONFIGURATION_NAME

public static final java.lang.String COMPILE_ONLY_CONFIGURATION_NAME

The name of the configuration that is used to declare dependencies which are only required to compile a component, but not at runtime.

COMPILE_ONLY_API_CONFIGURATION_NAME

public static final java.lang.String COMPILE_ONLY_API_CONFIGURATION_NAME

The name of the configuration to define the API elements of a component that are required to compile a component, but not at runtime.

RUNTIME_ONLY_CONFIGURATION_NAME

public static final java.lang.String RUNTIME_ONLY_CONFIGURATION_NAME

The name of the runtime only dependencies configuration, used to declare dependencies that should only be found at runtime.

RUNTIME_CLASSPATH_CONFIGURATION_NAME

public static final java.lang.String RUNTIME_CLASSPATH_CONFIGURATION_NAME

The name of the runtime classpath configuration, used by a component to query its own runtime classpath.

RUNTIME_ELEMENTS_CONFIGURATION_NAME

public static final java.lang.String RUNTIME_ELEMENTS_CONFIGURATION_NAME

The name of the runtime elements configuration, that should be used by consumers to query the runtime dependencies of a component.

JAVADOC_ELEMENTS_CONFIGURATION_NAME

public static final java.lang.String JAVADOC_ELEMENTS_CONFIGURATION_NAME

SOURCES_ELEMENTS_CONFIGURATION_NAME

public static final java.lang.String SOURCES_ELEMENTS_CONFIGURATION_NAME

COMPILE_CLASSPATH_CONFIGURATION_NAME

public static final java.lang.String COMPILE_CLASSPATH_CONFIGURATION_NAME

ANNOTATION_PROCESSOR_CONFIGURATION_NAME

public static final java.lang.String ANNOTATION_PROCESSOR_CONFIGURATION_NAME

TEST_IMPLEMENTATION_CONFIGURATION_NAME

public static final java.lang.String TEST_IMPLEMENTATION_CONFIGURATION_NAME

TEST_COMPILE_ONLY_CONFIGURATION_NAME

public static final java.lang.String TEST_COMPILE_ONLY_CONFIGURATION_NAME

The name of the configuration that should be used to declare dependencies which are only required to compile the tests, but not when running them.

TEST_RUNTIME_ONLY_CONFIGURATION_NAME

public static final java.lang.String TEST_RUNTIME_ONLY_CONFIGURATION_NAME

TEST_COMPILE_CLASSPATH_CONFIGURATION_NAME

public static final java.lang.String TEST_COMPILE_CLASSPATH_CONFIGURATION_NAME

TEST_ANNOTATION_PROCESSOR_CONFIGURATION_NAME

public static final java.lang.String TEST_ANNOTATION_PROCESSOR_CONFIGURATION_NAME

TEST_RUNTIME_CLASSPATH_CONFIGURATION_NAME

public static final java.lang.String TEST_RUNTIME_CLASSPATH_CONFIGURATION_NAME

Constructor Detail

JavaPlugin

Источник

Using Gradle Plugins

Gradle at its core intentionally provides very little for real world automation. All of the useful features, like the ability to compile Java code, are added by plugins. Plugins add new tasks (e.g. JavaCompile), domain objects (e.g. SourceSet), conventions (e.g. Java source is located at src/main/java ) as well as extending core objects and objects from other plugins.

In this chapter we discuss how to use plugins and the terminology and concepts surrounding plugins.

What plugins do

Applying a plugin to a project allows the plugin to extend the project’s capabilities. It can do things such as:

• Extend the Gradle model (e.g. add new DSL elements that can be configured)
• Configure the project according to conventions (e.g. add new tasks or configure sensible defaults)
• Apply specific configuration (e.g. add organizational repositories or enforce standards)

By applying plugins, rather than adding logic to the project build script, we can reap a number of benefits. Applying plugins:

• Promotes reuse and reduces the overhead of maintaining similar logic across multiple projects
• Allows a higher degree of modularization, enhancing comprehensibility and organization
• Encapsulates imperative logic and allows build scripts to be as declarative as possible

Types of plugins

There are two general types of plugins in Gradle, binary plugins and script plugins. Binary plugins are written either programmatically by implementing Plugin interface or declaratively using one of Gradle’s DSL languages. Binary plugins can reside within a build script, within the project hierarchy or externally in a plugin jar. Script plugins are additional build scripts that further configure the build and usually implement a declarative approach to manipulating the build. They are typically used within a build although they can be externalized and accessed from a remote location.

A plugin often starts out as a script plugin (because they are easy to write) and then, as the code becomes more valuable, it’s migrated to a binary plugin that can be easily tested and shared between multiple projects or organizations.

Using plugins

To use the build logic encapsulated in a plugin, Gradle needs to perform two steps. First, it needs to resolve the plugin, and then it needs to apply the plugin to the target, usually a Project.

Resolving a plugin means finding the correct version of the jar which contains a given plugin and adding it to the script classpath. Once a plugin is resolved, its API can be used in a build script. Script plugins are self-resolving in that they are resolved from the specific file path or URL provided when applying them. Core binary plugins provided as part of the Gradle distribution are automatically resolved.

Applying a plugin means actually executing the plugin’s Plugin.apply(T) on the Project you want to enhance with the plugin. Applying plugins is idempotent. That is, you can safely apply any plugin multiple times without side effects.

The most common use case for using a plugin is to both resolve the plugin and apply it to the current project. Since this is such a common use case, it’s recommended that build authors use the plugins DSL to both resolve and apply plugins in one step.

Binary plugins

You apply plugins by their plugin id, which is a globally unique identifier, or name, for plugins. Core Gradle plugins are special in that they provide short names, such as ‘java’ for the core JavaPlugin. All other binary plugins must use the fully qualified form of the plugin id (e.g. com.github.foo.bar ), although some legacy plugins may still utilize a short, unqualified form. Where you put the plugin id depends on whether you are using the plugins DSL or the buildscript block.

Locations of binary plugins

A plugin is simply any class that implements the Plugin interface. Gradle provides the core plugins (e.g. JavaPlugin ) as part of its distribution which means they are automatically resolved. However, non-core binary plugins need to be resolved before they can be applied. This can be achieved in a number of ways:

• Including the plugin from the plugin portal or a custom repository using the plugins DSL (see Applying plugins using the plugins DSL).
• Including the plugin from an external jar defined as a buildscript dependency (see Applying plugins using the buildscript block).
• Defining the plugin as a source file under the buildSrc directory in the project (see Using buildSrc to extract functional logic).
• Defining the plugin as an inline class declaration inside a build script.

For more on defining your own plugins, see Custom Plugins.

Applying plugins with the plugins DSL

The plugins DSL provides a succinct and convenient way to declare plugin dependencies. It works with the Gradle plugin portal to provide easy access to both core and community plugins. The plugins DSL block configures an instance of PluginDependenciesSpec.

To apply a core plugin, the short name can be used:

Источник