En fait, à partir du moment où java 8 est installé sur la machine, il suffit de lancer l’appli avec java -jar <nom-du-fichier-jar> et ça se lance tout seul. Je pourrais éventuellement fournir un script de lancement mais je ne suis pas sûr que cela améliore vraiment les choses.
Pour un informaticien ou un bidouilleu c’est sur mais pour un néophytes ou un handicapé du code… Sa peut aider. N’oublions pas Il y a qu’1%de personnes qui utilisent et sache utiliser cette outil formidable qu’est Linux…
Ah oui ce serait cool. Il faudrait qu’on trouve un moyen pour identifier de façon unique une partie (ou les utilisateurs), de façon à diminuer la probabilité que quelqu’un vienne pourrir les stats. Encore une fois je ne connais pas bien mais : serait-il possible de faire une délégation d’authentification à la Toile de Confiance via un système style OAuth ou OpenID ? Apparemment ça en parle sur le forum technique dans le sujet La WOT est une base d’authentification idéale!
Mais mon programme tourne aussi sous n’importe quel OS supporté par Java (c’est-à-dire quasiment tous). Il me faudrait donc faire plusieurs lanceurs en fonction du système, alors qu’on peut même le lancer par l’interface graphique. Bon, si ça amuse quelqu’un, il y a launch4j qui existe et qui permet de faire ce genre de choses.
Il faudrait quasiment tout refaire, même si le backend pourrait rester. Je suis parti du principe qu’on n’a pas forcément de réseau stable là où on est quand on organise le jeu, c’est pour ça que j’ai fait une version desktop totalement déconnectée.
Oui, ça fait un moment que j’aimerais développer un site web où chacun pourrait uploader les fichiers d’export des jeux pour ensuite faire des stats. C’est tout-à-fait faisable, on pourrait même le faire directement depuis l’appli. Et pour la sécurité, en attendant mieux il me serait assez simple d’ouvrir l’accès pour un nombre limité de personnes (ceux qui ont organisé un jeu avec le programme, ça doit se compter sur les doigts des deux mains peut-être, non ?).
Pour aller plus loin, utiliser les comptes membres est vraiment délicat en terme de sécurité. Plus on utilise nos identifiants de membre un peu partout, plus on a des chances de se les faire piquer. Alors, à moins de faire des clés dérivées, ça me paraît à proscrire pour ce genre d’utilisation.
@jytou je n’arrive pas a faire fonctionner gecohelper sur mon nouvel ordinateur. Je suis bien en version Java 8 mais avec l’openjdk.
J’ai essayé de télécharger le jdk de Oracle mais désormais il est obligatoire de créer un compte Oracle et de donner des informations personnelles (adresse, telephone, nom, prenom, etc) pour obtenir le jdk oracle. Il en est de même pour le jre seul.
Comment fait-on pour faire fonctionner gecohelper sur son ordinateur sans créer de compte Oracle ?
Si ce n’est pas possible, j’ai du mal a considéré gecohelper comme un logiciel libre
$ java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~18.04-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
$ java -jar gecohelper.jar
[EL Warning]: 2020-07-15 19:45:49.521--ServerSession(440434003)--Exception [EclipseLink-7274] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An Exception was thrown while trying to create logging file [gecoJPA.log]:[java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)].
Internal Exception: java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)
Exception in thread "main" Local Exception Stack:
Exception [EclipseLink-30005] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.PersistenceUnitLoadingException
Exception Description: An exception was thrown while searching for persistence archives with ClassLoader: sun.misc.Launcher$AppClassLoader@74a14482
Internal Exception: javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [geco] failed.
Internal Exception: Exception [EclipseLink-7274] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An Exception was thrown while trying to create logging file [gecoJPA.log]:[java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)].
Internal Exception: java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)
at org.eclipse.persistence.exceptions.PersistenceUnitLoadingException.exceptionSearchingForPersistenceResources(PersistenceUnitLoadingException.java:127)
at org.eclipse.persistence.jpa.PersistenceProvider.createEntityManagerFactoryImpl(PersistenceProvider.java:115)
at org.eclipse.persistence.jpa.PersistenceProvider.createEntityManagerFactory(PersistenceProvider.java:188)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:79)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:54)
at jyt.geconomicus.helper.HelperUI.main(HelperUI.java:1837)
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [geco] failed.
Internal Exception: Exception [EclipseLink-7274] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An Exception was thrown while trying to create logging file [gecoJPA.log]:[java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)].
Internal Exception: java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.createPredeployFailedPersistenceException(EntityManagerSetupImpl.java:2082)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:2073)
at org.eclipse.persistence.internal.jpa.deployment.JPAInitializer.callPredeploy(JPAInitializer.java:101)
at org.eclipse.persistence.jpa.PersistenceProvider.createEntityManagerFactoryImpl(PersistenceProvider.java:104)
... 4 more
Caused by: Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [geco] failed.
Internal Exception: Exception [EclipseLink-7274] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An Exception was thrown while trying to create logging file [gecoJPA.log]:[java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)].
Internal Exception: java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)
at org.eclipse.persistence.exceptions.EntityManagerSetupException.predeployFailed(EntityManagerSetupException.java:231)
... 8 more
Caused by: Exception [EclipseLink-7274] (Eclipse Persistence Services - 2.7.1.v20171221-bd47e8f): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An Exception was thrown while trying to create logging file [gecoJPA.log]:[java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)].
Internal Exception: java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)
at org.eclipse.persistence.exceptions.ValidationException.invalidLoggingFile(ValidationException.java:2672)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.updateLoggers(EntityManagerSetupImpl.java:1242)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1754)
... 6 more
Caused by: java.io.FileNotFoundException: gecoJPA.log (Permission non accordée)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
at java.io.FileOutputStream.<init>(FileOutputStream.java:101)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.updateLoggers(EntityManagerSetupImpl.java:1234)
... 7 more
le message d’erreur est pourtant très clair (joke inside ! )
Tu dois avoir un fichier gecoJPA.log dans le répertoire où tu lances gecohelper avec des permissions qui ne permettent pas à la JVM d’écrire dedans… ou bien peut-être que tu lances gecohelper à partir d’un répertoire où tu n’as pas les droits d’écriture…
Tiens-moi au courant, ça marche parfaitement avec l’openJDK normalement.
En effet ce fichier avait pour propriétaire root. Initialement gecohelper ne marchais pas en user donc j’avais essayé de le lancer en root puis j’ai compris plus tard que c’était parce que j’avais java 11.
J’ai modifié le propriétaire du fichier gecoJPA.log et effectivement ça fonctionne avec l’openJDK désormais, merci @jytou
Je suis rassuré de ne pas avoir besoin de créer un compte oracle
@jytou j’ai voulu testé la nouvelle option jetons 1-3 et j’ai remarqué que gecohelper faisait de la création monétaire par arrondi, ce que est très gênant, d’autant que c’est évitable !
Autre problème, on ne peut pas soumettre de MR sur le dépôt de gecohelper, sans doute un problème de droits trop restrictifs par défaut sur gitlab.com. Ce serait plus pratique que le dépôt de gecohelper soit sur le gitlab de duniter
J’ai creusé davantage et je confirme qu’il est effectivement possible de faire en sorte que les arrondis n’impactent jamais la masse monétaire mais cela pose deux problèmes :
Cela implique qu’un joueur qui renaît commencera aléatoirement à 3 ou 4, ce qui serait perturbant pour les joueurs.
Cela implique que le logiciel connaisse exactement le nombre de joueur que l’animateur va faire mourir AVANT de verser les DU → nécessiterait un changement de l’UX pour forcer l’animateur à traiter d’abord tous les morts puis ensuite tous les « DU/réévaluation ».
Un bon compromis est d’arrondir au-dessus pour les nouveaux nés (ce qui est déjà fait, car ils commencent à 4 au lieu de 3,5) et en dessous pour les autres joueurs : ce qui correspond finalement à la règle officielle, comme quoi Galuel avait déjà choisi un bon compromis pour minimiser l’impact des arrondis.
Ce serait bien que gecohelper propose au moins la possibilité d’arrondir comme dans les règles officielles, ce qui n’est actuellement pas le cas si on utilise l’option jetons 1-3.
J’ai testé l’option « pénalité d’un jeton » mais elle n’a pas le comportement que j’attends, les arrondis sont quand même au-dessus avec cette option activée, du coup je ne comprends ce que cette option est censée faire.
Désolé, pas de temps en ce moment… je regarderai ça… au pire il faut cloner sur le git de duniter, ce qui ne me dérange pas le moins du monde. Le code est à tous !
Bonjour à tous je suis nouveau sur Mxlinux19 et n’arrive pas à installer java 8 pour faire tourner gecnomicushelper, quelqu’un peut il m’aider?
voici le raport d’instal:
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1/rmid.1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/man/ja_JP.UTF-8/man1/rmiregistry.1
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1/rmiregistry.1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/man/ja_JP.UTF-8/man1/servertool.1
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1/servertool.1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/man/ja_JP.UTF-8/man1/tnameserv.1
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1/tnameserv.1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/man/ja_JP.UTF-8/man1/unpack200.1
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1/unpack200.1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/man/ja_JP.UTF-8/man1/javaws.1
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1/javaws.1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/man/ja
tar: jre1.8.0_271/man/ja_JP.UTF-8/man1 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/man/ja_JP.UTF-8 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/man/ja : un lien symbolique ne peut pas être créé vers « ja_JP.UTF-8 »: Opération non permise
jre1.8.0_271/plugin/
tar: jre1.8.0_271/man : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/plugin/desktop/
jre1.8.0_271/plugin/desktop/sun_java.desktop
tar: jre1.8.0_271/plugin/desktop/sun_java.desktop : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/plugin/desktop/sun_java.png
tar: jre1.8.0_271/plugin/desktop/sun_java.png : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/release
tar: jre1.8.0_271/plugin/desktop : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/plugin : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/release : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
jre1.8.0_271/THIRDPARTYLICENSEREADME-JAVAFX.txt
tar: jre1.8.0_271/THIRDPARTYLICENSEREADME-JAVAFX.txt : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/lib/amd64/server/libjsig.so : un lien symbolique ne peut pas être créé vers « ../libjsig.so »: Opération non permise
tar: jre1.8.0_271/lib/amd64/server : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/lib/amd64 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271/lib : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: jre1.8.0_271 : le propriétaire ne peut pas être changé en uid 10143, gid 10143: Opération non permise
tar: Arrêt avec code d'échec à cause des erreurs précédentes