group = "verification"
                        description = "Ensures the accepted api changes file is kept alphabetically ordered to make merging changes to it easier"
                        apiChangesDirectory = layout.projectDirectory.dir("${ TextUtil.normaliseFileSeparators(firstAcceptedApiChangesFile.parentFile.absolutePath) }")
                    }

   * and column pair, they will be combined with the specified merging function in encounter order.
   *
   * <p>The returned {@code Collector} will throw a {@code NullPointerException} at collection time
   * if the row, column, value, or merging functions return null on any input.
   *
   * @since 21.0
   */
  public static <T extends @Nullable Object, R, C, V>

    checkNotNull(mergeFunction, "mergeFunction");

    /*
     * No mutable Table exactly matches the insertion order behavior of ImmutableTable.Builder, but
     * the Builder can't efficiently support merging of duplicate values.  Getting around this
     * requires some work.
     */

    return Collector.of(
        ImmutableTableCollectorState<R, C, V>::new,
        (state, input) ->
            state.put(

 {{{http://www.slf4j.org/manual.html#swapping}"SLF4J bindings"}}.

 Logging configuration loading is actually done by logging implementation, without any Maven extensions to support merging
 Maven installation configuration with per-user configuration for example:
 <<<$\{maven.conf}/logging>>> directory was added to core's classpath (see <<<$\{maven.home}/bin/m2.conf>>>). See your implementation

import org.codelibs.fess.util.ComponentUtil;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestInfo;

/**
 * Test class for FessTransformer interface.
 * Tests the array handling improvements and data merging functionality.
 */
public class FessTransformerTest extends UnitFessTestCase {

    // Test implementation of FessTransformer for testing
    private static class TestFessTransformer implements FessTransformer {

                delete.delete(".settings");
            }
        });

        project.getTasks().named("cleanEclipse").configure(t -> t.dependsOn("wipeEclipseSettings"));

        // otherwise the eclipse merging is *super confusing*
        project.getTasks().named("eclipse").configure(t -> t.dependsOn("cleanEclipse", "copyEclipseSettings"));

        project.getPlugins().withType(JavaBasePlugin.class, javaBasePlugin -> {

                    <span class="btn btn-info" role="button">Merge release to master</span>
                  </summary>
                  <div class="well">
                    Merging `release` back to `master` is a regular operation you’re free to do, at any time. Usually, you will see conflicts in `notes.md` or `accepted-public-api-changes.json`.

import java.io.*;
import java.nio.charset.*;
import java.util.*;
import java.util.concurrent.*;
import java.util.stream.*;

/**
 * See https://github.com/gradle/gradle-private/issues/3919
 *
 * When merging `releaseX` branch into `master`, we should only use the release note from the `master` branch,
 * but sometimes changes on release notes.md was brought to master and merged unnoticed,
 * e.g https://github.com/gradle/gradle/pull/25825

[Rally](http://github.com/elastic/rally). Microbenchmarks are intended to spot performance regressions in performance-critical components.
The microbenchmark suite is also handy for ad-hoc microbenchmarks but please remove them again before merging your PR.

## Getting Started

Just run `gradlew -p benchmarks run` from the project root
directory. It will build all microbenchmarks, execute them and print
the result.

## Running Microbenchmarks

import org.apache.maven.api.model.ReportPlugin;
import org.apache.maven.api.model.Reporting;
import org.apache.maven.model.v4.MavenMerger;

/**
 * As long as Maven controls the BuildPomXMLFilter, the entities that need merging are known.
 * All others can simply be copied from source to target to restore the locationTracker
 *
 * @since 4.0.0
 * @deprecated use {@code org.apache.maven.api.services.ModelBuilder} instead
 */