Outils de Développement

• Obtenir le code via Git
• Développer avec le Code JMRI
• Git FAQs
• Construire avec:
  • Ant
  • NetBeans
  • Eclipse
  • IntelliJ IDEA

Structure du Code

• Introduction
• Application Structure
• Noms et Désignation
• Modèles de Structure du code
• Structure Swing
• Structure de Connexion Externe
• Liens
• Utilisation de XML
  • XML Schema
  • XSLT Formatting
• Site Web
• Javadocs
  • Index des Noms
  • Paquets
  • Hiérarchie des Classes

Techniques et Standards

• Pratiques Recommandées
• Intégration Continue
• Internationalisation
• Connexion & Gestion des erreurs
• Test Unitaire avec JUnit
• Documentation avec JavaDoc et UML
• Exécutez l'outil d'analyse statistique SpotBugs
• Fournir de l'aide avec Java
• Méthode Nom Portable
• XML Persistance

Comment Faire

• Etendre avec des Plugins
• Ajouter un Nouveau Type
• Ajouter un Nouveau Système

Infos Fonctionnelles

• Rétrosignalisation Aiguillage
• Connexions Réseau
• Comment les Scripts de Démarrage travaillent

Contexte Infos

• Technologie Roadmap
• Enquête sur les Capacités de JVM
• Sondage Utilisateur, Printemps 2007

Système d'Aide JMRI

Des pages marqué *) sont en Anglais.

Faites un don à JMRI.org

JMRI: Modèles et Organisation

JMRI a grandi et évolué avec le temps, et vous ne pouvez pas toujours voir les structures et les caractéristiques actuellement préférées en regardant des morceaux de l'ancien code.

Cette page tente de décrire la structure et les modèles recommandés, et fournir des exemples des meilleures pratiques actuelles.

Noms, NamedBeans, et les gestionnaires

Le concept "NameBean" est la base de JMRI. Un NamedBean est un objet de base qui représente quelque chose, typiquement quelque chose comme un Capteur ou un Aiguillage.

• Ils sont appelés "Bean" parce qu'ils sont une unité d'interaction: De multiples morceaux de code peuvent travailler avec l'un d'eux, il peut être chargé ou stocké, etc.
• Ils sont "named" parce que pour être sûr qu'ils sont uniques et retrouvables: Il y a seulement un Aiguillage NamedBean appelé LT01, et il représente un objet spécifique du réseau adressé( named ). Voir la page sur les Noms pour en savoir davantage.

Fonctionnellement, toutes les classes d'objets du système ( Capteur, Aiguillage,... ) et leurs mise en oeuvre spécifiques ( LnSensor, XNetTurnout, ...), hérite de la classe de base NamedBean.

Pour obtenir l'accès à un objet spécifique (un NamedBean d'un type spécifique avec un nom spécifique ), vous faites des demandes à un gestionnaire: vous demandez un TurnoutManager pour un Aiguillage spécifique à votre tour, vous accédez aux gestionnaires à travers l'InstanceManager commun.

Un utilisateur peut vouloir rééférencer un NamedBean via un nom utilisateur, et à son tour peut vouloir changer le NetBean spécifique auquel le nom utilisateur se réfère. "Yard East Turnout" peut être "LT12" à un point et plus tardpeut changer en "CT5". Pour gérer ceci, votre code utilise les objets NamedBeanHandle pour gérer les références pour NamedBeans. Ils automatisent le processus de renommage.

Organisation du Code

Au plus haut niveau, nous séparons le code de test du code distribué en les mettant dans des répertoires distincts dans le répertoire de développement: "test" et "src". Il est donc facile de compiler une version sans code de test, d'appliquer des outils différents pour les deux types de code, etc

Dans le code source lui-même, nous séparons plusieurs types.

Le paquet jmri

contient les interfaces de base pour le système. Il doit contenir le code de mise en œuvre minimale, et pas de références non-JMRI, en particulier le code Swing.

Le paquet jmri.jmris

Contient tout le code pour la mise en œuvre des serveurs pour les interfaces JMRI.

Le paquet jmri.jmrit

contient tout le code pour les outils JMRI non spécifiques au système et extensions La plupart des outils sont dans des sous-paquets, mais certains apparaissent directement dans le paquet

Le paquet jmri.jmrix

Contient tout le code pour se connecter à du matériel spécifique du réseau ferré.

Les paquetsjmri.managers et jmri.implementations

Ceux-ci fournissent des mises en œuvres par défaut pour les gestionnaires et les autres classes. Cela déplace le code du paquet primaire JMRI. Ils ne doivent pas répondre à des applications, jmri.jmrix ou jmri.jmrit.

paquet jmri.util

Autres mise en oeuvre courantes d'usage général. Ne devrait pas dépendre des paquets jmri.jmrit ou jmri.jmrix. Le sous-paquet jmri.util.swing fournit les utilitaires Swing

paquet Apps

Pour rassembler une application, cela peut dépendre de n'importe quoi.

Sous-répertoires configurexml

Ceux-ci contiennent le code pour le système de configuration XML les paquets de haut niveau, esp util & dependancies, apps.

Sous-répertoires swing

Contient les outils Swing spécifiques. En particulier à l'extérieur du paquet jmri.jmrit, nous essayons de séparer le code Swing du code normal opérationnel. Voir la page Swing pour plus d'informations.

Help files (fichiers d'aide)

La structure du fichier d'aide, les fichiers échos de la structure du code. Pour plus d'informations, voir la page d'aide dans les pages JavaHelp.

ResourceBundles

Nous utilisons le regroupements de ressources pour l'internationalisation. Elles sont colocalisée avec le code qui les référence, mais nous nous dirigeons vers une nouvelle convention de dénomination. Pour réduire le fardeau de chargement, nous nous dirigeons vers un modèle où le fichier jmri.foo.FooBundle.properties est adressé par un élément statique dans la classe jmri.foo.FooBundle, séparé des propriétés du fichier lui même. Cela réduit beaucoup le temps de chargement!
Notez qu'il existe également quelques regroupements de ressources qui sont utilisés à d'autres fins, indiqués dans leurs commentaires en tête.

Le script outil de développement "checkdepends.csh" est destiné à vérifier certaines des dépendances par inadvertance, mais nous sommes loin de l'effacer.

---