Evitar tener que listar todas las clases en el persistence.xml

[RaniAgus]

Recuerdo en su día haber hecho este descubrimiento y me olvidé de compartirlo: no hace falta listar todas las clases en el persistence.xml porque la property hibernate.archive.autodetection ya lo hace sola.

El problema está en los tests, que la autodetección no funciona porque solamente busca clases en test/ y no en main/. En un ticket de StackOverflow recuerdo haber encontrado este workaround: agregando algo al pom.xml y una línea en el persistence.xml ya está todo lo necesario para que ande la autodetección y prevenir altos dolores de cabeza 👍🏻

[flbulgarelli]

¡Hola! Gracias por la propuesta. Deshabilitar autodetection fue intencional, porque si bien en la realidad lo usarías, en el aula creemos que resulta más conveniente hacerlo de a un paso por vez, sobre todo cuando estás empezando a anotar tus primeras clases y tenés anotaciones incorrectas. Habilitar la funcionalidad de autodetection hace el proceso de pseudo-debugging más difícil.

De todas formas, entiendo que el filtering propuesto es útil en cualquier caso, así que a priori eso me parece que es algo que se podría incorporar, por un lado. Por el otro, se podría documentar en el README y/o en el propio persistence.xml cómo activar autodetection para quien prefiera hacerlo y dejar una advertencia sobre sus consecuencias.

¿Te parece cambiar este PR en esa dirección?

[RaniAgus]

Buenísimo, dale, como prefieran. Igual se podría crear una branch aparte (llamada, por ejemplo, configuracion-autodetection-filtering) y apuntar el PR ahí, así dejamos futbol-en-clase-2022-08-26 intacto cómo quedó después de la clase. Y, de paso, queda la branch con un nombre más expresivo para poder encontrarla 😅

No entendí sobre las consecuencias negativas que puede traer activar autodetection, ¿cuáles serían?

Por otro lado, ahí me puse a investigar un poco sobre Filtering y armé esta otra solución que permite aplicarlo solo en el persistence.xml sin afectar al resto de resources:

    <testResources>
      <testResource>
        <directory>src/test/resources</directory>
        <filtering>false</filtering>
        <excludes>
          <exclude>META-INF/persistence.xml</exclude>
        </excludes>
      </testResource>
      <testResource>
        <directory>src/test/resources</directory>
        <filtering>true</filtering>
        <includes>
          <include>META-INF/persistence.xml</include>
        </includes>
      </testResource>
    </testResources>

Sería útil si se usara algún otro template engine que tenga la misma forma de reemplazar variables del modelo, para evitar que el filtering modifique esos archivos produciendo efectos no deseados. Igual entiendo que en los tests uno no pondría templates, por lo que podría no hacer falta tanta "granularidad".

Avísenme si prefieren esta solución o la actual, así hago el cambio de ser necesario antes de redactar el README.