Guide du développeur - plaa/Modular GitHub Wiki
Cette page contient des informations sur le fonctionnement interne d'OpenRocket et est destinée principalement aux développeurs intéressés pour contribuer au développement d'OpenRocket.
En complément de cette page des informations peuvent être trouvées dans la documentation technique au chapitre 5.
OpenRocket est développé majoritairement en utilisant Eclipse, et c'est l'IDE recommandé pour la compatibilité. Les développeurs sont libres d'utiliser d'autres IDE mais tout ne fonctionnera peut être pas "out-of-the-box".
Vous avez besoin d'installer soit le plugin Eclipse Subclipse ou Subversive SVN client. Suivez les instructions sur leurs pages. Le deux plugins sont relativement similaires, mais la documentation ci dessous utilise la terminologie de Subclipse.
Après avoir installé Subclipse, sélectionnez File -> Import, puis sélectionnez "Checkout Projects from SVN" en dessous de "SVN" et cliquez Next. Vous avez besoin de créer un nouveau "repository" en utilisant l'URL https://openrocket.svn.sourceforge.net/svnroot/openrocket. Ensuite sélectionnez le répertoire "trunk" (c'est la branche de développement de base) et cliquez Finish. Après avoir tout chargé vous devriez avoir tous le code source dans un projet.
Note: Les packages sources disponibles sur le site d'OpenRocket (*.zip) sont destinés à construire l'application à partir du code source , et non pas dans le but de développer. Ils ne contiennent pas tous les fichiers du projet.
Pour ceux d'entre vous qui veulent utiliser la ligne de commande, le répertoire trunk d'OpenRocket peut être récupéré simplement par:
$ svn co https://openrocket.svn.sourceforge.net/svnroot/openrocket/trunk OpenRocket
Vous pouvez récupérer la version Galileo d'Eclipse sur le Site de téléchargement d'Eclipse. Vous devriez vous procurer soit l'IDE Eclipse pour les développeurs ou Eclipse pour RCP/Plug-in Developers. J'utilise l'IDE d'Eclipse pour les développeurs Java. Aucun d'entre eux ne se trouve en haut de la liste donc faites attention de choisir la bonne version.
Lorsque vous créez un espace de travail pour charger le projet, assurez vous de choisir le JRE par défaut et la compatibilité Java 1.6. Même si vous avez déjà configuré votre "system default" de l'ordinateur pour qu'il utilise Java 6 et que vous fassiez tourner votre IDE avec Java 6, les espaces de travail utiliseront par défaut Java 5. Vous devez utiliser la version 1.6 ou vous aurez de nombreuses erreurs de compilations - particulièrement autour de l'utilisation de @Override.
|
|
Si vous avez des erreurs regardez le "build path" et vérifiez que vous voyez 1.6 dans le "build path" comme montré plus haut.
Après avoir importé le projet dans Eclipse les bibliothèques devraient être configurées correctement automatiquement. Une autre étape additionnelle est nécessaire pour qu'OpenRocket puisse trouver le fichier build.properties pour lancer OpenRocket.
- Ouvrez la class net.sf.openrocket.startup.Startup. Lancer ceci directement ne fonctionne pas à cause du fichier manquant build.properties.
- Sélectionner Run As -> Run Configurations...
- Dans l'onglet Classpath cliquez sur User entries, ensuite cliquez Advanced... -> Add Folders -> Sélectionnez le répertoire de base d'OpenRocket et cliquez OK
- Cliquez Run
Souvent lorsque vous écrivez du code vous savez que quelque chose pourrai être mieux faite mais pour le moment c'est soit impossible soit déraisonnable. Dans ce cas ces choses sont généralement signalées avec un commentaire TODO. La convention qui suit est utilisée pour marquer l'importance de divers TODO:
-
// TODO: CRITICAL: Des commentaires
Un bug ou quelque chose qui n'est pas encore implémenté et doit être corrigé avant qu'une version soit faite. Le script Ant build les recherche et interrompt le 'Build' si ce type de commentaire est trouvé. -
// TODO: HIGH: Des commentaires
Un problème important qui devrait être regardé cette fois ci ou à la prochaine version majeure. -
// TODO: MEDIUM: Des commentaires
Quelque chose qui pourrai améliorer l'application mais qui ne constitue pas un problème en sois. -
// TODO: LOW: Des commentaires
Quelque chose qu'il serai bien de faire mieux dans le futur
Log messages in openrocket are specified by one of six levels. You can specify which level of errors you want reported to standard out with a system property which you can add to your VM argument, e.g:
-Dopenrocket.log.stdout=debug
The error levels available are:
- ERROR - Level for indicating a bug or error condition noticed in the software or JRE. No ERROR level events _should_ occur while running the program.
- WARN - Level for indicating error conditions or atypical events that can occur during normal operation (errors while loading files, weird computation results etc).
- USER - Level for logging user actions (adding and modifying components, running simulations etc). A user action should be logged as soon as possible on this level. The level is separate so that additional INFO messages won't purge user actions from a bounded log buffer.
- INFO - Level for indicating general level actions the software is performing and other notable events during execution (dialogs shown, simulations run etc)
- DEBUG - Level for indicating mid-results, outcomes of methods and other debugging information. The data logged should be of value when analyzing error conditions and what has caused them. Places that are called repeatedly during e.g. flight simulation should use the VBOSE level instead.
- VBOSE - Level of verbose debug logging to be used in areas which are called repeatedly, such as computational methods used in simulations. This level is separated to allow filtering out the verbose logs generated during simulations, DnD etc. from the normal debug logs.
log.verbose("Error message");
where log is defined in each class as :
private static final LogHelper log = Application.getLogger();
OpenRocket utilise toujours en interne des unités SI pures. Par exemple toutes les dimensions de la fusée et les distances de vol sont en mètres, toutes les masses sont en kilogrammes, la densité en kg/m³, la température en Kelvin etc. Cette convention est également utilisée lorsque le projet est stocké au format OpenRocket.
La seule exception à cette règle ce sont les angles:
- Les angles sont représentés en radians en interne mais dans le fichier ils sont convertis en degrés. Ceci est pour rendre le format de fichier plus facile à lire par un humain et pour éviter des erreurs d’arrondi.
- La latitude et la longitude du site de lancement sont représentés en degré à la fois en interne et en externe.
(Cette section est basé sur de la correspondance email )
Toutes les lectures/écritures de fichier sont faites dans le package net.sf.openrocket.file et ses subpackages. Pour implémenter un nouveau "document loader" il est nécessaire d’étendre la class RocketLoader et d’implémenter la méthode "abstract" loadFromStream(InputStream). Cette méthode se contente simplement de charger le document OpenRocketDocument et retourne un objet.
Un OpenRocketDocument contient toutes les informations concernant un document ouvert , principalement la structure de la fusée et les simulations. La structure de la fusée est une structure simple en arbre des RocketComponents. Toutes les pièces sont dans le package .rocketcomponent. Un diagramme de leur hiérarchie et une courte explication de chaque class est disponible dans ma thèse à la section 5.1 (http://openrocket.sourceforge.net/documentation.html)
J'ai implémenté un framework XML simple en lecture (basé sur SAX), qui simplifie la lecture en prenant comme supposition que les éléments XML peuvent contenir d'autres éléments ou du texte mais pas les deux. A la fois les formats OpenRocket et Rocksim ont la même restriction.
Le framework est dans le package .file.simplesax. The primary class that will be extended is ElementHandler, which contains three methods. openElement() is called when a new subelement is found, and it returns a new ElementHandler to handle that element (which can be the object itself), or null in order to ignore that element and all of its contents (for example for unknown elements). closeElement() is called when the subelement ends, and endHandler() is called when the element of the current handler ends. The JavaDoc should provide the necessary details.
There are a few ready handlers, the most useful of which will probably be PlainTextHandler. This handler accepts only text content and ignores all subelements. If the XML file contains <element>value</element>, then the handler can return a PlainTextHandler and handle the content within the closeElement() method, removing the need to write a specialized handler for that element.
The XML reading is initiated by calling SimpleSAX.readXML() with the input source and the initial ElementHandler.
The OpenRocket document loading is implemented in .file.openrocket.OpenRocketLoader. Here I've used a bit more boilerplate code to be able to define most of the rocket structure preferences without needing separate handlers for them.
Le format natif d'OpenRocket utilise l'extension de fichier *.ork. C'est un format XML, qui peut être optionnellement compressé en utilisant GZIP. (L'extension *.ork.gz est également accepté par les dialogues, bien que le .ork non compressé soit recommandé.)
Pour le moment le format de fichier n'est pas documenté autrement que dans l’implémentation de référence et aucun schéma XML existe. Cela changera espérons le dans le future. Consultez #Unités utilisés dans OpenRocket pour plus de détails sur les unités.
Chaque fois que le format XML change, le numéro de version du fichier est incrémenté. Ce numéro de version n'est pas lié à la version d'OpenRocket qui a créé le fichier mais à la place décri le format de fichier. Les versions plus récentes d'OpenRocket devraient essayer de sauvegarder les fichiers dans l'ancien format qui contient toutes les fonctionnalités nécessaires. Les changements dans le format sont décris dans le fichier fileformat.txt présent dans SVN. Italic text