testcontainers / testcontainers/testcontainers-java

[Enhancement]: Shrink size of core-jar / Rethink shading

Abierto
#8,612 0 comentarios 4 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

type/enhancement
Lenguaje dominante
Java
Estrellas
8.7k
Forks
1.9k
Merge medio
2 d 17 h
PR fusionados (30 d)
9

Descripción

Module

Core

Proposal

The testcontainers jar file currently has a size of a whopping 17MB (packed; unpacked 34MB), making it by far one of the biggest maven dependencies I know of.

Most of the size (>97%; 33MB) seems to come from shaded artifacts inside org.testcontainers.shaded.

A full list of disadvantages of shading can be found in JLBP-18.

I think the jar could be a lot smaller. Here a few ways how this could be tackled:

  • Check if all the shaded dependencies are required in the core module in the first place. I check the core module and couldn't find any class that implements: org.hamcrest, org.checkerframework, org.bouncycastle or org.awaitability.
    There are also other libraries that could be easily replaced, e.g. guava as it's only used in a few places and uses nowadays standard java stuff. Removing these 5 libs alone would shrink the lib by 23MB or 67% alone.
  • Maybe don't use shading at all and publish a bom that contains the exact versions of the required dependencies, that way there should also be no dependency conflicts

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza en el módulo Core e inspecciona cómo se declaran los artefactos sombreados y se empaquetan en el jar de testcontainers. Revisa qué dependencias enumeradas son necesarias, mide los tamaños del jar empaquetado y desempaquetado, y compara los enfoques de shading y BOM. Se considera terminado cuando haya una estrategia de dependencias decidida que reduzca el jar de Core sin romper a sus consumidores.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
java
Área
build-system
Tipo de issue
Refactorización
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.