<commit_before>
This spec describes some work to allow plugins to define the kinds of components that they produce and consume.

## A note on terminology

There is currently a disconnect in the terminology used for the dependency management component model, and that used
for the component model provided by the native plugins.

The dependency management model uses the term `component instance` or `component` to refer to what is known as a `binary`
in the native model. A `component` in the native model doesn't really have a corresponding concept in the dependency
management model (a `module` is the closest we have, and this is not the same thing).

Part of the work for this spec is to unify the terminology. This is yet to be defined.

For now, this spec uses the terminology from the native component model, using `binary` to refer to what is also
known as a `component instance` or `variant`.

# Stories

## Feature: Build author declares a Java library

For example:

    apply plugin: 'new-java' // TBD - needs a better identifier

    libraries {
        myLib {
            // Infer the type by the available set of library types
        }
    }

    binaries {
        // A Java library binary is visible here
    }

This defines a Java library that:
- Has a single Java source set hardcoded to `src/myLib/java`
- Has a single resources source set hardocoded to `src/myLib/resources`
- Has no dependencies
- Produces a jar binary as output from the source.
- Has a lifecycle task to build the jar.

It should be possible to declare multiple libraries for a given project.

### Open issues

- Need a better id for the plugin, to sync up with the native plugins.
- Make the library type explicit, rather than infer it? Possibly with a type, possibly by naming the container.
- The legacy JVM language plugins should also declare a jvm library.
- The legacy application plugin should also declare a jvm application.
- Move everything to the rules model.

## Feature: Build author declares that a Java library depends on a Java library produced by another project

For example:

    apply plugin: 'new-java'

    libraries {
        myLib {
            dependencies {
                project 'other-project' // Infer the target library<commit_msg>Spec updates<commit_after>
This spec describes some work to allow plugins to define the kinds of components that they produce and consume.

## A note on terminology

There is currently a disconnect in the terminology used for the dependency management component model, and that used
for the component model provided by the native plugins.

The dependency management model uses the term `component instance` or `component` to refer to what is known as a `binary`
in the native model. A `component` in the native model doesn't really have a corresponding concept in the dependency
management model (a `module` is the closest we have, and this is not the same thing).

Part of the work for this spec is to unify the terminology. This is yet to be defined.

For now, this spec uses the terminology from the native component model, using `binary` to refer to what is also
known as a `component instance` or `variant`.

# Features

## Feature: Build author declares a Java library

For example:

    apply plugin: 'new-java' // TBD - needs a better identifier

    libraries {
        myLib {
            // Infer the type by the available set of library types
        }
    }

    binaries {
        // A Java library binary is visible here
    }

This defines a Java library that:
- Has a single Java source set hardcoded to `src/myLib/java`
- Has a single resources source set hardocoded to `src/myLib/resources`
- Has no dependencies
- Produces a jar binary as output from the source.
- Has a lifecycle task to build the jar.

It should be possible to declare multiple libraries for a given project.

### Story: Build author defines java library

#### Test cases

- Can apply plugin without defining library
    - No binaries defined
    - No lifecycle task added
- Define a java library component
    - JvmLibraryBinary added to binaries container
    - Lifecycle task available to build binary
    - Can add dependent tasks to binary

### Story: Build author builds jar for java library

#### Test cases

- Define and build the jar for a java library (assert jar contents for each case)
    - With no sources or resources
    - With sources but no resources
    - With resources but no sources
    - With both sources and resources
- Reports failure to compile library
- Compiled sources and resources are separate

### Story: Build author defines multiple java libraries in single project

#### Test cases

- Define and build multiple java libraries in the same project
  - Build library jars individually using binary lifecycle task
  - `gradle assemble` builds single jar for each library
- `gradle clean` removes compiled sources, copied resources and generated jar for each library

### Story: Legacy JVM language plugins declare a jvm library

#### Test cases

- JVM library with name 'main' is defined with any combination of `java`, `groovy` and `scala` plugins applied
- Can build legacy jvm library jar using standard lifecycle task
- When a library named 'main' is defined with the new plugin, conform to the naming conventions of the legacy plugin

### Open issues

- Need a better id for the plugin, to sync up with the native plugins.
- Make the library type explicit, rather than infer it? Possibly with a type, possibly by naming the container.
- The legacy application plugin should also declare a jvm application.
- Move everything to the rules model.

## Feature: Build author declares that a Java library depends on a Java library produced by another project

For example:

    apply plugin: 'new-java'

    libraries {
        myLib {
            dependencies {
                project 'other-project' // Infer the target library
{'fraction_non_alphanumeric': 0.04807855087184696, 'fraction_numerical': 0.0, 'mean_word_length': 3.3827893175074184, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6739752', 'n_tokens_mistral': 1420, 'n_tokens_neox': 1378, 'n_words': 871}