The I18n team is pleased to announce the i18n-3.0 release! Nuiton i18n tools Documentation of the project can be found here: https://maven-site.nuiton.org/i18n Important Note -------------- This major version makes it now compatible with java 1.8 (see issue 2687). The I18n class api has changed, follow the migration guide to use this new version: https://maven-site.nuiton.org/i18n/migrate.html Changes ------- Changes in this version include: New features: o Rename I18n methods to be compatible with jre 8 Issue: 2687. Thanks to Tony Chemit. Resolved by tchemit. o Add new AST parser for java file Issue: 1586. Thanks to Éric Chatellier. Resolved by echatellier. Fixed Bugs: o Commented keys are parsed in GWT parser mojo Issue: 1535. Thanks to Florian DESBOIS. Resolved by fdesbois. Changes: o Updates mavenpom to 4.7 Issue: 3030. Thanks to Tony Chemit. Resolved by tchemit. o Updates xwork-core to 2.3.16 Issue: 3026. Thanks to Tony Chemit. Resolved by tchemit. o Updates plexus-utils to 3.0.17 Issue: 3025. Thanks to Tony Chemit. Resolved by tchemit. o Update to commons-collections4 Issue: 2941. Thanks to Éric Chatellier. Resolved by tchemit. o Remove deprecated parser (jsp and tapestry) Issue: 3020. Thanks to Tony Chemit. Resolved by tchemit. Maven artifacts --------------- Artifacts are deployed in Maven Central Repository http://repo1.maven.org/maven2/ Find us at * http://search.maven.org/#artifactdetails|org.nuiton|i18n|3.0|jar Have fun! -I18n team -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Le 04/02/2014 11:20, Tony Chemit a écrit :
o Rename I18n methods to be compatible with jre 8 Issue: 2687. Thanks to Tony Chemit. Resolved by tchemit. Bonjour,
N'était-il pas possible d'avoir une version transitoire où _() aurait été dépréciée ? Cette version transitoire aurait pu, de plus, durer un moment, car _() provoque un warning sous java 8 et pas encore une vraie erreur. La migration vers I18n 3.0 est très brutale pour IsisFish. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
On Wed, 05 Feb 2014 10:10:54 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 04/02/2014 11:20, Tony Chemit a écrit :
o Rename I18n methods to be compatible with jre 8 Issue: 2687. Thanks to Tony Chemit. Resolved by tchemit. Bonjour,
N'était-il pas possible d'avoir une version transitoire où _() aurait été dépréciée ? Cette version transitoire aurait pu, de plus, durer un moment, car _() provoque un warning sous java 8 et pas encore une vraie erreur.
La migration vers I18n 3.0 est très brutale pour IsisFish.
Il y a juste une commande sh à passer, c'est pas très compliqué à appliquer selon moi. Personne n'oblige à l'utiliser en fait, comme personne n'oblige les utilisateurs d'isisfish de se mettre sur un EAP de la jdk8, non? Vous avez encore plus d'un mois pour migrer. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Le 05/02/2014 10:13, Tony Chemit a écrit :
Il y a juste une commande sh à passer, c'est pas très compliqué à appliquer selon moi. Pour le code d'IsisFish, oui la commande sh ira très bien.
par contre, pour les scripts utilisateurs, ce n'est pas possible. Avec du code déprécié, il aurait pu avoir plusieurs années pour migrer en douceur. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
On Wed, 05 Feb 2014 10:20:33 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 05/02/2014 10:13, Tony Chemit a écrit :
Il y a juste une commande sh à passer, c'est pas très compliqué à appliquer selon moi. Pour le code d'IsisFish, oui la commande sh ira très bien.
par contre, pour les scripts utilisateurs, ce n'est pas possible. Avec du code déprécié, il aurait pu avoir plusieurs années pour migrer en douceur.
Il font du I18n dans des scripts utilisateur ? Et ils les mettent où les traductions ? Je ne comprends pas le cas pratique. Je réitère alors ma proposition qu'il migre en douceur vers java 8 en plusieurs années aussi :D Si tu veux fait un ticket pour qu'on fasse en version à part pour isis-fish (ça sera alors plus une 2.x). Et puis 3.0 c'est bien une version majeure donc avec possibilité de changement d'API, ce qui a été le cas. Désolé pour la gène mais il me parait très difficile de pouvoir avancer si y'a toujours des wagons à raccrocher :( tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Le 05/02/2014 10:26, Tony Chemit a écrit :
Si tu veux fait un ticket pour qu'on fasse en version à part pour isis-fish (ça sera alors plus une 2.x).
Done http://nuiton.org/issues/3071 Merci. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
Le 07/02/2014 18:44, Eric Chatellier a écrit :
Done http://nuiton.org/issues/3071 En fait, je pense que la release 2.9 ne servira à rien car toutes les librairies utilisant ont été ou sont en cours de mise à jour vers i18n 3.0 sans passer par une phase de compatibilité, donc impossible d'utiliser i18n 2.9 dans ce cas: nuiton-matrix, jaxx, topia...
-- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
En fait, je pense que la release 2.9 ne servira à rien car toutes les librairies utilisant ont été ou sont en cours de mise à jour vers i18n 3.0 sans passer par une phase de compatibilité, donc impossible d'utiliser i18n 2.9 dans ce cas: nuiton-matrix, jaxx, topia... Ha si, en restant spécifiquement sur la 2.9 dans le projet final ça restera
Le 25/02/2014 11:09, Eric Chatellier a écrit : peut-être "binary compatible" un moment ? -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
On Tue, 25 Feb 2014 11:09:27 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 07/02/2014 18:44, Eric Chatellier a écrit :
Done http://nuiton.org/issues/3071 En fait, je pense que la release 2.9 ne servira à rien car toutes les librairies utilisant ont été ou sont en cours de mise à jour vers i18n 3.0 sans passer par une phase de compatibilité, donc impossible d'utiliser i18n 2.9 dans ce cas: nuiton-matrix, jaxx, topia...
Je peux plus rien pour toi, à ce niveau là, je ne vais pas refaire n releases pour une hypotéthique migration... Mais les utilisateurs n'utilisent pas jaxx? topia lequel? as-tu discuté sur topia-devel de la migration d'isis ? je n'ai rien vu passer à ce sujet :( Arranges toi avec les utilisateurs d'isis-fish pour qu'ils migrent ou pas. On ne peut pas toujours être freiner dans ce sens; il me semble qu'il y a des budgets alloué à Isis-fish; ils peuvent servir un peu à ça aussi. autre solution : tu fais les releases. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Le 25/02/2014 11:22, Tony Chemit a écrit :
Je peux plus rien pour toi, à ce niveau là, je ne vais pas refaire n releases pour une hypotéthique migration... Mais les utilisateurs n'utilisent pas jaxx? topia lequel? as-tu discuté sur topia-devel de la migration d'isis ? je n'ai rien vu passer à ce sujet :( Le problème porte sur i18n en tant que dépendance des projets sus-nommés, pas des projets eux mêmes.
Arranges toi avec les utilisateurs d'isis-fish pour qu'ils migrent ou pas. On ne peut pas toujours être freiner dans ce sens; il me semble qu'il y a des budgets alloué à Isis-fish; ils peuvent servir un peu à ça aussi.
autre solution : tu fais les releases. Pour moi, la solution me semble simple. Il n'y a, je pense, pas de problème à avoir l'ancienne api et la nouvelle dans la branche 3.x, pendant un ou deux ans, voire même jusqu'à Java 9. Et et i18n 4.x, l'ancienne api pourrait être supprimée. Cela laisse tout le temps au projet de migrer.
Y a-t-il une contre indication à ne pas procéder comme ça ? -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
On Tue, 25 Feb 2014 18:53:20 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 25/02/2014 11:22, Tony Chemit a écrit :
Je peux plus rien pour toi, à ce niveau là, je ne vais pas refaire n releases pour une hypotéthique migration... Mais les utilisateurs n'utilisent pas jaxx? topia lequel? as-tu discuté sur topia-devel de la migration d'isis ? je n'ai rien vu passer à ce sujet :( Le problème porte sur i18n en tant que dépendance des projets sus-nommés, pas des projets eux mêmes.
Arranges toi avec les utilisateurs d'isis-fish pour qu'ils migrent ou pas. On ne peut pas toujours être freiner dans ce sens; il me semble qu'il y a des budgets alloué à Isis-fish; ils peuvent servir un peu à ça aussi.
autre solution : tu fais les releases. Pour moi, la solution me semble simple. Il n'y a, je pense, pas de problème à avoir l'ancienne api et la nouvelle dans la branche 3.x, pendant un ou deux ans, voire même jusqu'à Java 9. Et et i18n 4.x, l'ancienne api pourrait être supprimée. Cela laisse tout le temps au projet de migrer.
Y a-t-il une contre indication à ne pas procéder comme ça ?
Je ne suis pas pour se tramballer des casseroles qaund on sait l'usage fait d'i18n dans Isis community (=null, ils ne traduisent rien). Je te suggère alors d'utiliser la version 2.9 et de faire des exclusions dans isis sur les autres libraires, ça devrait fonctionner non ? Benjamin m'a dit tout à l'heure qu'on a la main sur tous les scripts. Pour moi le plus simple c'est de virer des n_() des scripts, plus que de garder des api dépréciées des années. On ne parle pas non plus ici d'une communautés de milliers d'utilisateurs avec des milliers de fichiers, non? Toute proportion gardée, tu dois pouvoir gérer ça en moins d'une heure je pense. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
On Tue, 25 Feb 2014 18:53:20 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 25/02/2014 11:22, Tony Chemit a écrit :
Je peux plus rien pour toi, à ce niveau là, je ne vais pas refaire n releases pour une hypotéthique migration... Mais les utilisateurs n'utilisent pas jaxx? topia lequel? as-tu discuté sur topia-devel de la migration d'isis ? je n'ai rien vu passer à ce sujet :( Le problème porte sur i18n en tant que dépendance des projets sus-nommés, pas des projets eux mêmes.
Arranges toi avec les utilisateurs d'isis-fish pour qu'ils migrent ou pas. On ne peut pas toujours être freiner dans ce sens; il me semble qu'il y a des budgets alloué à Isis-fish; ils peuvent servir un peu à ça aussi.
autre solution : tu fais les releases. Pour moi, la solution me semble simple. Il n'y a, je pense, pas de problème à avoir l'ancienne api et la nouvelle dans la branche 3.x, pendant un ou deux ans, voire même jusqu'à Java 9. Et et i18n 4.x, l'ancienne api pourrait être supprimée. Cela laisse tout le temps au projet de migrer.
Y a-t-il une contre indication à ne pas procéder comme ça ?
Je me rends compte que la version 2.9, j'ai fait une connerie, y'a pas la méthode _ :( mais la méthode t_ à la place, merdum... -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
On Tue, 25 Feb 2014 18:53:20 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 25/02/2014 11:22, Tony Chemit a écrit :
Je peux plus rien pour toi, à ce niveau là, je ne vais pas refaire n releases pour une hypotéthique migration... Mais les utilisateurs n'utilisent pas jaxx? topia lequel? as-tu discuté sur topia-devel de la migration d'isis ? je n'ai rien vu passer à ce sujet :( Le problème porte sur i18n en tant que dépendance des projets sus-nommés, pas des projets eux mêmes.
Arranges toi avec les utilisateurs d'isis-fish pour qu'ils migrent ou pas. On ne peut pas toujours être freiner dans ce sens; il me semble qu'il y a des budgets alloué à Isis-fish; ils peuvent servir un peu à ça aussi.
autre solution : tu fais les releases. Pour moi, la solution me semble simple. Il n'y a, je pense, pas de problème à avoir l'ancienne api et la nouvelle dans la branche 3.x, pendant un ou deux ans, voire même jusqu'à Java 9. Et et i18n 4.x, l'ancienne api pourrait être supprimée. Cela laisse tout le temps au projet de migrer.
Y a-t-il une contre indication à ne pas procéder comme ça ?
J'avais compris que ça ne compilait plus si dans le code il y avait des _, ce qui n'est pas le cas; c'est juste dans des functions lambda. donc on peut se l'autoriser. J'ai donc réintroduit les méthodes _, n_ et t_. (https://forge.nuiton.org/issues/3096). -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
participants (2)
-
Eric Chatellier -
Tony Chemit