// Check if mixins are present without flattening enabled
        if (!model.getMixins().isEmpty() && !flattenEnabled && !model.isPreserveModelVersion()) {
            throw new MavenException("The consumer POM for "
                    + project.getId()
                    + " cannot be created because the POM contains mixins. "
                    + "Mixins are not supported in the default consumer POM format. "

        <!-- Mixins                                                                 -->
        <!-- ====================================================================== -->

        <field xdoc.separator="blank">
          <name>mixins</name>
          <version>4.2.0+</version>
          <description>Mixins...</description>
          <association>
            <type>Mixin</type>

are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.
  - Improvements to Maven configuration.

Guidelines for any code contributions:

1.  Any significant changes should be accompanied by tests. The project already

These issues are more complex and might be challenging for first-time contributors.

You can share your interest in fixing the issue by commenting on it.
If somebody shared their interest in the issue, please consider letting them work on it.
However, if there are no changes for more than a week, it's safe to assume that the issue is up for grabs.

1. Read existing code first (use symbol overview tools)
2. Follow existing patterns
3. Add tests
4. Handle resources properly (try-with-resources)
5. Consider thread safety
6. Update JavaDoc

### When Fixing Bugs

1. Write failing test first
2. Understand root cause
3. Minimal changes
4. Verify no regressions

### When Refactoring

1. Preserve behavior
2. Keep tests green

    return get_model_fields(model)  # type: ignore[return-value]


# Duplicate of several schema functions from Pydantic v1 to make them compatible with
# Pydantic v2 and allow mixing the models

TypeModelOrEnum = Union[type["BaseModel"], type[Enum]]
TypeModelSet = set[TypeModelOrEnum]


def normalize_name(name: str) -> str:
    return re.sub(r"[^a-zA-Z0-9.\-_]", "_", name)

				t.Errorf("%s#%d got %q want %q", prefix, i, err, tt.errStr)
			}
		}
	}

	const maxInt = int(^uint(0) >> 1)

	runTestCases("", []testCase{
		0: {"--", -2147483647, "negative"},
		1: {"", maxInt, ""},
		2: {"-", 10, ""},
		3: {"gopher", 0, ""},
		4: {"-", -1, "negative"},
		5: {"--", -102, "negative"},

      - name: Run Tests
        run: ./gradlew test allTests -Dokhttp.platform=bouncycastle

  testcorretto:
    runs-on: ubuntu-latest
    # TODO add master build after fixing all tests in CI
    if: contains(github.event.pull_request.labels.*.name, 'providers')

    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Configure JDK

* `docs`: Docs
    * Changes in docs. This includes updating the docs, fixing typos. But it doesn't include changes to translations.

Go's emphasis on backwards compatibility is one of its key strengths.
There are, however, times when we cannot maintain complete compatibility.
If code depends on buggy (including insecure) behavior,
then fixing the bug will break that code.
New features can also have similar impacts:
enabling the HTTP/2 use by the HTTP client broke programs
connecting to servers with buggy HTTP/2 implementations.