En théorie, exclure les dépendances transitives que tu n'utilises pas ne pose pas de problème. Tu pourrais diminuer drastiquement la taille de l'appli je pense, mais tu sais à quoi tu t'exposes (risques de ClassNotFound si tu as exclu une dépendance en trop), à toi de voir. Personnellement, je rejoins l'avis de Tony : >7Mo, ça n'a rien de choquant. Si j'étais toi, je dépenserai mon énergie dans d'autre chantiers. ++ Arnaud Le 29/02/2016 15:32, Eric Chatellier a écrit :
Bonjour,
jTimer étant toujours trop gros (> 7 Mo zippé) par rapport à ce qu'il fait, voici l'état des dépendances et des possibilités d'amélioration.
Par taille de dépendance: - freemarker (1,4Mo) : utile pour les rapport, mais voir pour utiliser mustache à la place ? - swingx-core (1.2Mo) : librairie sous utilisées, mais quand même quelques composant difficile à remplacer - jna (1.1Mo) : pas possible de faire mieux à cause du code natif (so, dll) des plateformes cibles - log4j-core (1.1Mo) : c'est gros pour ce que c'est, voir pour un remplacant ? logback (450k) ? - commons-collection4 (600k) : dépendance de nuiton-config - commons-collection (600k) : dépendance de nuiton-config - commons-lang3 (450k) : on doit pouvoir s'en passer avec java 8, mais ... dépendance de nuiton-config - nuiton-utils : dépendance de nuiton-config - commons-beanutils: dépendance de nuiton-config - commons-io: pourrait ne pas être utilisée, mais fonctions bien pratique car la File API de java 7 a des manques - nuiton-config: utile pour ApplicationConfig - (et il en reste)