Eclipse Java organisation du dossier de projet
J'arrive à Java et Eclipse à partir d'un arrière-plan C #/Visual Studio. Dans ce dernier, j'organiserais normalement une solution comme ceci:
\ MyProjects\MyApp\MyAppsUtilities\LowerLevelStuff
où MyApp contiendrait un projet pour construire un .exe, MyAppsUtilities ferait un Assembly DLL appelé par le .exe, et LowerLevelStuff construirait probablement un Assembly contenant des classes utilisées par la DLL des utilitaires de niveau supérieur .
Dans Eclipse (Ganymède, mais pourrait être convaincu de passer à Galileo), j'ai:
\ MyProjects\workspace\MyApp
Quand je crée mon projet initial. Il y a une option pour mettre les fichiers source et créer dans le même dossier, mais j'ai des fichiers .Java créés sur un chemin qui reflète ma hiérarchie de packages:
\ MyProjects\workspace\MyApp\src\com\mycompany\myapp\MyApp.Java
Ma question est la suivante: lorsque je crée des sous-projets (est-ce le bon terme Java/Eclipse?) Pour les fichiers .jar qui seront analogues aux DLL MyAppsUtilities et LowerLevelStuff Assembly ci-dessus dans .NET, puis-je (dois-je) organiser les dossiers de manière équivalente? Par exemple.:
\ MyProjects\workspace\MyApp\src\com\mycompany\myapp\myapputilities\MyAppsUtilities.Java
Quelle est la manière standard/correcte d'organiser ce genre de choses, et comment cela se fait-il spécifiquement dans l'IDE?
Considérez Java les packages de code source comme un grand espace de noms hiérarchique. Les applications commerciales vivent généralement sous ' com.mycompany.myapp ' (le site Web de cette application peut être 'http: //myapp.mycompany.com 'bien que ce ne soit évidemment pas toujours le cas).
La façon dont vous organisez les choses sous votre package myapp dépend en grande partie de vous. La distinction que vous faites pour C # entre l'exécutable (.exe), les DLL et les classes de bas niveau n'existe pas sous la même forme en Java. Tout le code source Java est compilé dans des fichiers .class (dont le contenu est appelé "bytecode") qui peuvent être exécutés par une machine virtuelle Java (JVM) sur de nombreuses plates-formes. Il n'y a donc pas de distinction inhérente dans les classes de haut niveau/bas niveau, sauf si vous attribuez de tels niveaux via votre packaging. Un moyen courant d'emballage est:
- com.mycompany.myapp : classe principale; MyApp (avec une méthode principale)
- com.mycompany.myapp.model : classes de modèle de domaine; Client, commande, etc.
- com.mycompany.myapp.ui : code de l'interface utilisateur (présentation ou vue)
- com.mycompany.myapp.service : services au sein de votre application, c'est-à-dire `` logique métier ''
- com.mycompany.myapp.util : classes d'assistance utilisées à plusieurs endroits
cela suggère une application Java autonome, elle peut être différente s'il s'agit d'une application Web utilisant l'un des nombreux cadres.
Ces packages correspondent à une hiérarchie de répertoires dans votre projet. Lorsque vous utilisez Eclipse, la racine d'une telle hiérarchie est appelée "répertoire source". Un projet peut définir plusieurs répertoires source, généralement un répertoire source "principal" et "test".
Exemple de fichiers dans votre projet:
src/test/Java/com/acme/foo/BarTest.Java
src/main/Java/com/acme/foo/Bar.Java
lib/utilities_1_0.jar
Et dans utilities_1_0.jar:
com/acme/foo/BarUtils.class
BarUtils.class c'est une classe Java compilée, donc sous forme de bytecode indépendant de la plateforme qui peut être exécuté sur n'importe quelle JVM. Habituellement, les fichiers jar contiennent uniquement les classes compilées, bien que vous puissiez parfois télécharger une version du fichier jar qui contient également les fichiers source (.Java). Ceci est utile si vous souhaitez pouvoir lire le code source d'origine d'un fichier jar que vous utilisez.
Dans l'exemple ci-dessus, Bar, BarTest et BarUtils sont tous dans le même package com.acme.foo mais résident physiquement à différents emplacements sur votre disque dur.
Les classes qui résident directement dans un répertoire source sont dans le `` package par défaut '', ce n'est généralement pas une bonne idée d'y conserver les classes car il n'est pas clair à quelle société et application appartient la classe et vous pouvez obtenir des conflits de nom si un fichier jar que vous ajoutez à votre chemin de classe contient une classe du même nom dans le package par défaut.
Maintenant, si vous déployez cette application, elle serait normalement compilée dans des fichiers .class et regroupée dans un .jar (qui est essentiellement un nom de fantaisie pour un fichier .Zip plus quelques informations de manifeste). Créer un .jar n'est pas nécessaire pour exécuter l'application, mais pratique lors du déploiement/de la distribution de votre application. En utilisant les informations du manifeste, vous pouvez rendre un fichier .jar "exécutable", afin qu'un utilisateur puisse facilement l'exécuter, voir [a].
Habituellement, vous utiliserez également plusieurs bibliothèques, c'est-à-dire des fichiers .jar existants que vous avez obtenus sur Internet. Des exemples très courants sont log4j (un cadre de journalisation) ou des bibliothèques JDBC pour accéder à une base de données, etc. Vous pouvez également avoir vos propres sous-modules qui sont déployés dans des fichiers jar séparés (comme "utilities_1_0.jar" ci-dessus). La répartition des choses sur les fichiers jar est une question de déploiement/distribution, ils partagent toujours tous l'espace de noms universel pour le code source Java. Donc, en fait, vous pouvez décompresser tous les fichiers jar et mettre le contenu dans une grande structure de répertoires si vous le souhaitez (mais ce n'est généralement pas le cas).
Lorsque vous exécutez une application Java qui utilise/se compose de plusieurs bibliothèques, vous rencontrez ce qui est communément appelé "enfer de chemin de classe". L'un des plus gros inconvénients de Java tel que nous le connaissons. (note: l'aide est censée être en route ). Pour exécuter une application Java sur la ligne de commande (c'est-à-dire pas depuis Eclipse), vous devez spécifier chaque emplacement de fichier .jar sur le chemin de classe. Lorsque vous utilisez l'un des nombreux cadres Java (Maven, Spring, OSGi, Gradle), il existe généralement une forme de support pour soulager cette douleur. Si vous créez une application Web, il vous suffit généralement de respecter ses conventions de superposition/déploiement pour pouvoir déployer facilement la chose dans le conteneur Web de votre choix (Tomcat, Jetty, Glassfish).
J'espère que cela donne un aperçu général du fonctionnement des choses en Java!
[a] Pour créer un fichier exécutable de l'application MyApp, vous avez besoin d'un JDK sur votre chemin. Utilisez ensuite la ligne de commande suivante dans votre répertoire de compilation (bin ou cible):
jar cvfe myapp.jar com.mycompany.myapp.MyApp com\mycompany\myapp
Vous pouvez ensuite l'exécuter à partir de la ligne de commande avec:
Java -jar myapp.jar
ou en double-cliquant sur le fichier jar. Notez que vous ne verrez pas la console Java dans ce cas, donc cela n'est utile que pour les applications qui ont leur propre interface graphique (comme une application Swing) ou qui peuvent s'exécuter en arrière-plan (comme un serveur de socket).
Maven a une pensée bien pensée disposition de répertoire standard . Même si vous ne l'utilisez pas directement Maven, vous pouvez considérer cela comme une norme de facto. Les projets "multi-modules" Maven sont une analogie équitable avec la disposition d'assemblage multiple .net que vous avez décrite.
Il y a deux choses que vous devez clarifier avant de pouvoir répondre à cette question:
- Quel référentiel de code source utiliserez-vous?
- Quel système de build utiliserez-vous pour construire automatiquement des artefacts en dehors d'Eclipse?
Les réponses influenceront fortement vos options.
Nous avons opté pour "un composant pr du projet Eclipse" qui peut être soit une bibliothèque, soit un pot exécutable/exécutable fini. Cela a facilité l'automatisation avec Hudson. Notre utilisation de CVS est également plus facile, car les projets individuels n'ont pas de responsabilités multiples.
Remarque, chaque projet peut contenir plusieurs dossiers source séparant par exemple testez le code de la configuration de Java source. Ce n'est pas aussi important que de simplifier votre structure.
En règle générale, vous créez des projets/sous-projets associés en tant que différents projets dans Eclipse.