plugins {
    id("gradlebuild.distribution.api-java")
}

description = "Adds support for assembling web application EAR files"

errorprone {
    disabledChecks.addAll(
        "DefaultCharset", // 2 occurrences
        "StringCaseLocaleUsage", // 1 occurrences
    )
}

dependencies {
    api(libs.groovy)
    api(libs.inject)
    api(libs.jsr305)

    api(project(":base-services"))
    api(project(":core-api"))

 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

plugins {
    id("gradlebuild.distribution.api-java")
}

description = "Adds support for assembling JVM web application WAR files"

dependencies {
    api(project(":language-jvm"))
    api(project(":base-services"))
    api(project(":core"))
    api(project(":core-api"))

    api(libs.groovy)

 * #DEFAULT_SETTINGS_FILE}</code> settings file. Before Gradle assembles the projects for a build, it creates a
 * <code>Settings</code> instance and executes the settings file against it.</p>
 *
 * <h3>Assembling a Multi-Project Build</h3>
 *
 * <p>One of the purposes of the <code>Settings</code> object is to allow you to declare the projects which are to be

----

== Common tasks

The following are task conventions applied by built-in and most major Gradle plugins.

=== Computing all outputs
It is common in Gradle builds for the `build` task to designate assembling all outputs and running all checks:

----
$ gradle build
----

=== Running applications

The third step doesn't happen at all — unless you create a task to do it — because Gradle typically uses the files in the dependency cache directly in classpaths and as the source for assembling application packages.

Let's look in more detail at how Ivy's steps map to Gradle:

Configuration::

// THE SOFTWARE.

package mips

import (
	"cmd/internal/obj"
	"cmd/internal/objabi"
	"cmd/internal/sys"
	"fmt"
	"log"
	"sort"
)

// ctxt0 holds state while assembling a single function.
// Each function gets a fresh ctxt0.
// This allows for multiple functions to be safely concurrently assembled.
type ctxt0 struct {
	ctxt       *obj.Link
	newprog    obj.ProgAlloc

// license that can be found in the LICENSE file.

package loong64

import (
	"cmd/internal/obj"
	"cmd/internal/objabi"
	"fmt"
	"log"
	"sort"
)

// ctxt0 holds state while assembling a single function.
// Each function gets a fresh ctxt0.
// This allows for multiple functions to be safely concurrently assembled.
type ctxt0 struct {
	ctxt       *obj.Link
	newprog    obj.ProgAlloc

	// Generate a trampoline for a call from s to rs if necessary. ri is
	// index of the relocation.
	Trampoline func(ctxt *Link, ldr *loader.Loader, ri int, rs, s loader.Sym)

	// Assembling the binary breaks into two phases, writing the code/data/
	// dwarf information (which is rather generic), and some more architecture
	// specific work like setting up the elf headers/dynamic relocations, etc.

						<!-- Add bin directory -->
						<data>
							<type>files</type>
							<paths>
								<path>${project.basedir}/src/main/assemblies/files/fess</path>
								<path>${project.basedir}/src/main/assemblies/files/fess.in.sh</path>
								<path>${project.basedir}/src/main/assemblies/files/generate-thumbnail</path>
								<path>${project.basedir}/plugin.xml</path>
							</paths>
							<dst>${packaging.fess.bin.dir}</dst>

	// status of the pod from the kubelet's perspective (other components own the individual
	// elements of status) and should be consulted by components in preference to assembling
	// that status themselves. Note that the status manager is downstream of the pod worker
	// and components that need to check whether a pod is still running should instead directly
	// consult the pod worker.