Jgrapht: Modularisation du JDK 9

Quelqu'un pourrait-il me l'attribuer ? Je ne suis pas répertorié comme contributeur, donc je ne peux pas m'attribuer.

Merci!

J'ai déjà résolu quelques problèmes dans la branche master. Vous devez récupérer les modifications et continuer à partir de là. Merci.

Ça ira!

Pour référence future, les problèmes d'espace blanc XML et les problèmes d'annotation générés par jmh ont été corrigés dans #457.

Il y a aussi une faute de frappe dans le module touchgraph, où le module est appelé "demo" au lieu de "touchgraph".

Il y a aussi une faute de frappe dans le module touchgraph

ARGH ! Belle prise... Je ne sais pas comment j'ai réussi celle-là.

OK, j'ai donc écrit quelques descripteurs de module provisoires pour les modules core et io , mais j'ai dû utiliser le nom de module généré automatiquement antlr4.runtime comme la demande d'extraction Antlr. pas encore été accepté. Cela devra évidemment être remplacé par le vrai nom du module si et quand ils l'acceptent.

Le code se compile correctement et réussit tous les tests avec les descripteurs de module en place, donc je pense qu'il ne s'agit maintenant que d'obtenir les dépendances restantes pour publier les entrées Automatic-Module-Name . L'un d'entre eux ( jgraph ) semble ne pas être maintenu, il semble donc peu probable qu'il en publie un jamais... Je vais devoir examiner quelle est la meilleure pratique dans cette situation.

Hm, échec lié à Javadoc dans Travis... Vérifier ce qui ne va pas.

Le problème est que l'agrégation javadoc est actuellement interrompue dans l'outil Javadoc si l'un des modules du projet n'a pas de descripteur de module. Il n'y a pas encore de solution de contournement ; il s'agit en fait d'un bogue connu dans le JDK et devrait être corrigé dans Java 10.

Hm, donc nous ne pouvons pas inclure la modularisation de Java 9, avant la sortie du JDK 10 :) ?
Je doute que nous soyons en mesure de mettre à jour jgraph vers une version plus récente de sitôt. jgraph est toujours en cours de développement, mais les auteurs ne publient pas de nouvelles versions sur maven central, nous ne pouvons donc inclure aucune des versions les plus récentes.
En attendant, il peut toujours être utile d'ouvrir un PR qui résout autant de problèmes que possible (descripteurs de modules si possible, versions de plugins mises à jour, etc.)

Hm, donc nous ne pouvons pas inclure la modularisation de Java 9, avant la sortie du JDK 10 :) ?

Eh bien, je peux corriger le problème en écrivant des descripteurs de module pour tous les modules (ce que j'avais prévu de faire de toute façon). C'est juste que les modules restants ont des dépendances qui n'ont pas encore été modularisées.

Je doute que nous soyons en mesure de mettre à jour jgraph vers une version plus récente de sitôt

Si les auteurs ne sont pas réceptifs à pousser vers Central, il vaudrait peut-être la peine de maintenir un fork dans l'organisation jgrapht qui suit en amont mais publie également les noms de modules et pousse vers Central. Je pense que ce serait assez facile à mettre en place.

En attendant, il peut encore être utile d'ouvrir un PR

Oui, c'est toujours en cours.

Quelqu'un a-t-il une opinion sur la façon de gérer legacy-jgraph5 ?

J'aimerais faire bouger les choses, mais nous sommes actuellement bloqués sur le "travail que d'autres personnes doivent faire".

Y a-t-il une raison pour laquelle nous avons toujours une dépendance à l'égard de JGraph (plutôt que de simplement JGraphX) ? Je suppose que la réponse est que le JGraphXAdapter n'est pas complet, mais je suppose que cela est basé sur le fait que JGraphModelAdapter.java est 1041 LOC, alors que JGraphXAdapter n'est que 309 LOC.

Si c'est vrai, alors la bonne façon de résoudre ce problème est de terminer le JGraphXAdapter et d'abandonner JGraph pour de bon.

Je me demande si vous seriez prêt à diviser le module jgrapht-ext .

Je trouve qu'un endroit assez efficace pour tracer les limites des modules est le long des lignes de dépendances obligatoires. Ainsi, par exemple, le module jgrapht-ext dépend à la fois de jgraph et de jgraphx . Je pourrais vouloir seulement utiliser le code jgraph , ou je pourrais seulement vouloir utiliser le code jgraphx , mais le module ne me donne pas le choix. Je reçois les deux ou aucun. Je pense qu'un moyen plus efficace (en supposant qu'il n'y ait pas d'interdépendance entre les classes) serait de publier à la place des modules jgrapht-ext-jgraph et jgrapht-ext-jgraphx . De cette façon, nous pourrions publier un module jgrapht-ext-jgraph en supposant qu'il n'y aura jamais de nouvelle version jgraph et donc peu importe que le module dépende d'un artefact non modulaire ( car il n'y a aucune chance que cet artefact soit ultérieurement mis à niveau vers un module avec un Automatic-Module-Name approprié ou un vrai descripteur de module). Le module jgrapht-ext-jgraphx dépendrait du PR que je suis sur le point d'ouvrir pour ce projet.

J'ai un grand nombre de projets qui sont tous en cours de modularisation et un grand nombre d'entre eux dépendent de jgrapht-core , donc j'ai hâte que la modularisation se produise dès que possible. :sweat_smile:

Notez que cela nécessiterait de diviser le package org.jgrapht.ext et serait donc un changement révolutionnaire pour l'API. Il n'est pas permis que deux modules contiennent le même package ("le problème du split package") et nous devrions donc déplacer les classes vers org.jgrapht.ext.jgraph et org.jgrapht.ext.jgraphx .

J'aimerais d'abord comprendre pourquoi nous avons toujours la dépendance jgraph. S'il est obsolète, nous devons simplement dire aux utilisateurs que s'ils souhaitent l'utiliser, ils doivent également utiliser une ancienne version de JGraphT.

Je suis toujours en faveur de l'extraction du code mort. J'ai supposé qu'il était conservé pour une raison importante, mais l'éliminer impitoyablement est aussi une option !

@d-michail d'après ce que je peux dire, vous avez été la dernière personne à pénétrer dans le territoire de JGraph... avez-vous une opinion sur la possibilité de l'abandonner ?

Terence Parr vient de me faire savoir qu'il a l'intention de regarder le PR d'ANTLR dans trois jours environ, donc j'espère que cela bougera bientôt.

On dirait que vous faites un excellent travail pour aider les projets à aller de l'avant avec la modularisation, @io7m , donc en tant qu'observateur, je voulais juste dire que j'applaudis vos efforts et j'espère que les choses se

@jsichi Je ne sais pas vraiment si les gens l'utilisent encore.

Peut-être pouvons-nous envisager de créer un projet parallèle contenant les deux adaptateurs et l'application de démonstration (et utilisant une version spécifique de la bibliothèque jgrapht en tant que dépendance).

@d-michail bonne idée. Je vais poster sur jgrapht-users... si nous obtenons les grillons habituels comme réponse, alors je dirais que nous devrions simplement supprimer la dépendance JGraph, ne laissant que JGraphX. Si quelqu'un répond, nous pouvons suggérer le projet parallèle comme voie à suivre.

Est-ce que jgrapht suit le versionnage sémantique ? Je me souviens vaguement d'avoir lu quelque part que c'était le cas, mais maintenant je ne peux pas le trouver.

Le fait est que la suppression de la classe devrait remplacer la version principale.

Nous utilisons actuellement le versionnage de cowboy ; c'est-à-dire "quelle est la taille de cette version et depuis combien de temps la dernière s'est-elle écoulée ?" :) Nous devrions probablement devenir plus sérieux à ce sujet.

Nous essayons de suivre une politique de dépréciation, mais dans ce cas, comme JGraph lui-même est déprécié depuis des lustres, je pense que nous pouvons l'ignorer. Jusqu'à présent, je n'ai entendu aucune réponse de la liste de diffusion, je vais donc commencer à travailler sur une pull request pour supprimer la dépendance JGraph.

ANTLR PR vient d'être fusionné.

@ io7m Si PR https://github.com/jgrapht/jgrapht/pull/532 est fusionné, vous devrez probablement également ajouter un nom de module automatique au module adaptateur Guava qui y est développé.

Obtenez jgraphx pour publier un nom de module (jgraph/jgraphx#93)
Il semble que travis jette une erreur sur jgraph/jgraphx#93 ? Pourriez-vous jeter un œil à cela afin que nous puissions conclure celui-ci ? La dépendance jgraph a été supprimée, nous devrions donc nous en rapprocher.

@jkinable Il semble que leurs versions Travis CI échouent depuis un certain temps. Si vous vérifiez leur historique de construction, ce n'est qu'un échec après l'autre... :sweat:

Je ne pensais pas que j'avais rendu les choses pires qu'elles ne l'étaient déjà.

Je suis d'accord. Est-ce la seule chose qui nous bloque en ce moment ?

Je ne pense pas qu'une nouvelle version d'ANTLR ait encore été faite. Le PR a été fusionné, mais nous avons évidemment besoin de nouveaux artefacts pour arriver à Maven Central.

D'accord, jgraphx a fusionné vos relations publiques. Nous devons maintenant attendre qu'Antlr et jgraphx libèrent et publient de nouveaux artefacts. On se rapproche :)

mise à jour : une nouvelle version de jgraphx est sortie :)
Il ne reste plus qu'à attendre antlr...

Je viens d'avoir des indications que la sortie d'ANTLR ne sera pas... bientôt.

Je suis plutôt impatient de faire bouger les choses. Que ressentiriez-vous si je poussais une copie de ce qui deviendra vraisemblablement la version 4.7.2 d'ANTLR à un com.io7m.antlr ID de groupe ? Nous pourrions l'utiliser comme une dépendance temporaire jusqu'à ce que la vraie version d'ANTLR soit faite. Cela impliquerait seulement de pointer le POM sur com.io7m.antlr:antlr:4.7.2 , les descripteurs de module pourraient rester les mêmes.

Existe-t-il un fil de discussion public pour la version ANTLR ?

Seul le PR : https://github.com/antlr/antlr4/pull/2223

Ils semblent en moyenne environ neuf mois entre les versions. La dernière version date de décembre 2017, donc je suppose que la prochaine sera dans environ quatre mois.

Je ne pense pas que nous prévoyions nous-mêmes une autre version avant cette date, il est donc probablement logique d'attendre au lieu de brouiller les dépendances. Mais je ne voudrais pas être accusé du meurtre (meurtre par pitié ?) de Sisyphe. @d-michail et @jkinable des avis ?

Héhé, pas de soucis. Mon impatience est due au fait que j'ai ce graphe géant de dépendances, et j'ai besoin d'en mettre un en bas afin de pouvoir mettre à jour tout le reste. Celui du bas a besoin d'une nouvelle version de jgrapht pour être disponible (car la modularisation est une condition de la version).

Je préférerais juste attendre la prochaine version d'Antlr. Cela arrivera probablement avant notre prochaine sortie !

Je suppose que je pourrais pousser ma propre version de jgrapht à un com.io7m.jgrapht groupId juste pour sortir ce truc de la porte. Je vais également le pousser avec un qualificatif différent afin qu'il soit clair pour tout le monde que ce n'est pas équivalent à ce qui sera finalement la version 1.3.0 jgrapht .

Cela devrait être bien; nous allons essayer de ne pas introduire de nouvelles dépendances non-modularisées en attendant :)

On dirait qu'il y a enfin du mouvement à ce sujet :

https://github.com/antlr/antlr4/issues/2395

@io7m Enfin là ! Merci pour le dur travail. Devons-nous apporter d'autres modifications ? Je ne sais pas si nos dernières dépendances sont correctes !

Super!

Je vérifie les dépendances maintenant.

La bibliothèque jheaps a probablement besoin d'être ajustée. Aucun problème depuis que j'écris celui-là.

Ouais, c'est vrai. Je ne vois pas de Automatic-Module-Name ou de module-info.class dans le pot 0.9 jheaps

@d-michail : Je pense que ce serait également utile si jheaps publiait des métadonnées OSGi. Les modules jgrapht actuels le font déjà avec le maven-bundle-plugin .

Bon point

github l'a fermé automatiquement lorsque j'ai fusionné #731 ... veuillez rouvrir s'il y a plus à faire

@ io7m Nous

• savez-vous ce qu'il faudrait pour ajouter un support de module approprié à jgrapht?
• quel serait l'impact de l'ajout de modules à jgrapht pour les utilisateurs, par exemple, cela signifie-t-il que les utilisateurs doivent également utiliser des modules ?
• seriez-vous prêt à soumettre un PR avec support de module ?

La raison pour laquelle je pose cette question est que nous sommes confrontés à des problèmes avec notre version de pré-version. Lorsque vous essayez de compiler cette branche de jgrapht avec Java JDK 14 à l'aide de la commande mvn package -DskipTests , nous obtenons l'erreur ci-dessous. Nous pensons que cela est lié à un problème de module. Ce serait super si vous pouviez y jeter un œil !

[INFO] Reactor Summary for JGraphT - Parent 1.4.1-SNAPSHOT:
[INFO] 
[INFO] JGraphT - Parent ................................... SUCCESS [  0.690 s]
[INFO] JGraphT - Core ..................................... SUCCESS [ 26.257 s]
[INFO] JGraphT - I/O ...................................... FAILURE [  5.957 s]
[INFO] JGraphT - Optimized Graphs ......................... SKIPPED
[INFO] JGraphT - Ext ...................................... SKIPPED
[INFO] JGraphT - Guava Adapter ............................ SKIPPED
[INFO] JGraphT - Demo ..................................... SKIPPED
[INFO] JGraphT - Bundle ................................... SKIPPED
[INFO] JGraphT - Distributable Archives ................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  33.369 s
[INFO] Finished at: 2020-06-04T09:38:41-07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:jar (attach-javadoc) on project jgrapht-io: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1 - /home/ANT.AMAZON.COM/kinable/workspace/research/external/jgrapht/jgrapht/jgrapht-io/src/main/java/org/jgrapht/nio/gexf/SimpleGEXFEventDrivenImporter.java:22: error: package org.xml.sax is not visible
[ERROR] import org.xml.sax.*;
[ERROR]               ^
[ERROR]   (package org.xml.sax is declared in module java.xml, but module org.jgrapht.io does not read it)
[ERROR] /home/ANT.AMAZON.COM/kinable/workspace/research/external/jgrapht/jgrapht/jgrapht-io/src/main/java/org/jgrapht/nio/gexf/SimpleGEXFEventDrivenImporter.java:23: error: package org.xml.sax.helpers is not visible
[ERROR] import org.xml.sax.helpers.*;
[ERROR]                   ^
[ERROR]   (package org.xml.sax.helpers is declared in module java.xml, but module org.jgrapht.io does not read it)
[ERROR] /home/ANT.AMAZON.COM/kinable/workspace/research/external/jgrapht/jgrapht/jgrapht-io/src/main/java/org/jgrapht/nio/gexf/SimpleGEXFEventDrivenImporter.java:25: error: package javax.xml is not visible
[ERROR] import javax.xml.*;
...

Salut!

Oui, je peux y jeter un œil dans quelques jours. Avoir Java 11 comme dépendance minimale facilite certainement les choses car vous n'avez rien à faire comme placer les descripteurs de module dans META-INF/versions afin d'apaiser les utilisateurs d'anciens JDK. Il semble que j'ai écrit des descripteurs de module il y a quelque temps, mais ils se trouvent dans une branche périmée de mon fork. Cependant, cela ne devrait pas être difficile de tout mettre à jour.

quel serait l'impact de l'ajout de modules à jgrapht pour les utilisateurs, par exemple, cela signifie-t-il que les utilisateurs doivent également utiliser des modules ?

Cela ne signifie pas que les utilisateurs devront également utiliser des modules ; si cela était vrai, alors toute personne qui n'utilisait pas actuellement de modules ne pourrait pas du tout utiliser le JDK pour le moment. :le sourire:

Je pense que, parce que vous avez commencé à publier un Automatic-Module-Name il y a longtemps, la plupart des IDE et des outils de construction placeront déjà les fichiers jgrapht dans le chemin du module, par opposition à l'ancien chemin de classe. La publication de descripteurs explicites renforcera l'encapsulation et brisera le code de quiconque fait actuellement quelque chose de méchant, comme regarder de manière réfléchie les champs privés dans jgrapht . Vous pouvez éviter cette casse en marquant les paquets comme open , mais personnellement, je pense que quiconque fait ce genre d'accès réfléchissant non autorisé demande des ennuis en premier lieu !

Génial, merci Marc !

Le jeu. 4 juin 2020 à 14:10 Mark Raynsford [email protected]
a écrit:

Salut!

Oui, je peux y jeter un œil dans quelques jours. Avoir Java 11 comme
une dépendance minimale facilite certainement les choses car vous n'avez pas à le faire
quelque chose comme placer les descripteurs de module dans META-INF/versions dans
afin d'apaiser les gens avec d'anciens JDK. On dirait que j'ai écrit le module
descripteurs il y a quelque temps, mais ils sont assis dans une branche éventée dans ma fourchette.
Cependant, cela ne devrait pas être difficile de tout mettre à jour.

quel serait l'impact de l'ajout de modules à jgrapht pour les utilisateurs, par exemple
cela signifiera-t-il que les utilisateurs devront également utiliser des modules ?

Cela ne signifie pas que les utilisateurs devront également utiliser des modules ; si c'était
vrai alors toute personne qui n'utilisait pas actuellement de modules ne serait pas en mesure de
utiliser le JDK du tout maintenant. ??

Je crois que, parce que vous avez commencé à publier un Automatic-Module-Name a
il y a longtemps, la plupart des IDE et des outils de construction placeront déjà le
jgrapht jars dans le chemin du module par opposition à l'ancien chemin de classe.
La publication de descripteurs explicites renforcera l'encapsulation et
briser le code de toute personne qui fait actuellement quelque chose de méchant comme
en regardant les champs privés dans jgrapht de manière réfléchie. Vous pouvez éviter cela
casse en marquant les colis comme ouverts, mais personnellement, je pense que quiconque fait
ce genre d'accès réflexif non autorisé pose des problèmes dans le
première place!

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/jgrapht/jgrapht/issues/484#issuecomment-639118043 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAU5RSSGYJA22V5F24CZM2DRVAEUVANCNFSM4EQFK3TA
.