// 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>

                } else if ("".equals(artifact.getClassifier())) {
                    mains.add(artifact);
                }
            }
        }
        if (!mains.isEmpty() && !consumers.isEmpty()) {
            ArrayList<Artifact> result = new ArrayList<>(artifacts);
            for (Artifact main : mains) {
                result.remove(main);
                if (deployBuildPom) {

This is in contrast to the **development** stages, where you are constantly changing the code, breaking it and fixing it, stopping and restarting the development server, etc.

## Deployment Strategies { #deployment-strategies }

There are several ways to do it depending on your specific use case and the tools that you use.

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

* **Moins de bugs** : Réduit d'environ 40 % les erreurs induites par le développeur. *
* **Intuitif** : Excellente compatibilité avec les IDE. <abbr title="également connu sous le nom d'auto-complétion, autocomplétion, IntelliSense">Complétion</abbr> complète. Moins de temps passé à déboguer.
* **Facile** : Conçu pour être facile à utiliser et à apprendre. Moins de temps passé à lire la documentation.

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)

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

  public void testIsEqualToNull_serialization() {
    checkSerialization(Predicates.equalTo(null));
  }

  /**
   * Tests for Predicates.instanceOf(x). TODO: Fix the comment style after fixing annotation
   * stripper to remove comments properly. Currently, all tests before the comments are removed as
   * well.
   */
  @GwtIncompatible // Predicates.instanceOf
  public void testIsInstanceOf_apply() {