Quel est l'avantage de la 'src/main/java" convention?

J'ai remarqué que beaucoup de projets ont la structure suivante:

  • Projet
    • bin
    • lib
    • src
      • principal
        • java
          • RootLevelPackageClass.java

Actuellement, je utiliser la convention suivante (que mes projets sont 100% java):

  • Projet
    • bin
    • lib
    • src
      • RootLevelPackageClass.java

Je ne suis pas actuellement à l'aide de Maven mais je me demande si c'est une Maven convention ou pas ou si il y a une autre raison. Quelqu'un peut m'expliquer pourquoi la première version est si populaire ces jours-ci et si je dois adopter cette nouvelle convention ou pas?

Chris

InformationsquelleAutor Chris | 2010-06-09
  1. 55

    Principal avantage est d'avoir un test répertoire comme répertoire de src avec la même structure de répertoire que celui dans main:

    • Projet
      • bin
      • lib
      • src
        • principal
          • java
            • RootLevelPackageClass.java
          • ressources
        • test
          • java
            • TestRootLevelPackageClass.java
          • ressources

    Tous les colis privé méthodes de RootLevelPackageClass sera visible, c'est à dire testable de TestRootLevelPackageClass. Depuis le code de test est aussi la source de sa place devrait être sous src répertoire.

    • Habituellement, le répertoire des ressources est également divisée en src/main/resources et src/test/resources.
    • Sauer grâce. fixe.
    • J'utilise une convention comme l'OP, et je suis en mesure de mettre le code de test dans le même package que le code source de l'affaire (projet/src/com... et projet/test/com...). Je peux voir pourquoi il serait bien de diviser les ressources, mais je dois dire que je n'ai jamais eu besoin de tester les ressources spécifiques.
    • Aussi, si votre projet utilise plus d'une langue, ils sont assis bien au sein de la src/main/ et src/test de la structure. Vous pourriez avoir de la src/main/groovy, src/main/kotlin, src/main/jython etc. La JVM dispose désormais d'une multitude d'autres langues de côté à partir de Java.
    InformationsquelleAutor Boris Pavlović
  2. 23

    Oui, c'est le Maven convention.

    Même si votre projet est de 100% Java (comme d'habitude avec Maven btw), vous avez souvent des fichiers de ressources (qui vont à src/main/resources selon le Maven convention), ou une application web, ou ... tous ces éléments s'insèrent dans le Maven système facilement.

    Si vous êtes heureux avec votre version actuelle du système (quel qu'il soit), il n'y a aucune raison de passer à Maven. Sinon, ou si le démarrage d'un nouveau projet, vous pouvez évaluer vos options, y compris Maven.

    InformationsquelleAutor Péter Török
  3. 13

    D'autres l'ont déjà dit, c'est une Maven convention, je vais répondre à votre question plutôt:

    Absolument aucun. Certes, il est utile de séparer les morceaux de code pour séparer les dossiers racine, mais, habituellement, vous pouvez obtenir la même chose avec

    • [racine]
      • src
        • com.org.net
          • Your.class
      • test
        • com.org.net
          • YourTest.class
      • lib
      • bin
      • ressources

    à la place. En fait, c'est une grande chose que Maven ne fait énormément mal: Il veut ajouter du contenu binaire à référentiel de code source qui est utilisé pour le contenu de texte seulement! Tous les binaires d'un contenu doivent être gérées en dehors du référentiel de code source, qui comprend des images dans les applications web, et ainsi de suite.

    Mais OK, supposons que vous avez décidé de vivre dans la un peu malodorante Maven de l'écosystème; alors vous devriez, bien sûr, suivre les conventions de Maven aussi strictement que possible.

    • Salut, Merci pour vos commentaires. La structure que vous montrez dans votre réponse est similaire à la structure que j'utilise dans mes projets existants et de la convention jusqu'à Maven, il me semble. Je serais intéressé par vos autres points de vue de Maven et ce que vous recommandez pour le multi-projet construit comme une alternative et pourquoi (gradle/ant/ivy ...)?
    • Bien sûr, je vais modifier en plus de choses, plus tard aujourd'hui.
    • Le code Source de repos, malgré le nom, sont destinés à des binaires ainsi que le contenu textuel. Peut-être que vos projets n'ont pas de dépendances sur les biens binaires, mais toutes mes récentes (web) projets ont un visuel (ou sonores), et ils ne veulent pas fonctionner sans eux. Ils font partie intégrante du projet. C'est très bénéfique pour les avoir de version avec le "code". Ne les ayant pas voudrais juste faire le travail de chacun plus difficile.
    • La plupart des systèmes de gestion des versions sont fabriqués pour le contenu textuel et très peu de soutien bon versioning de contenu binaire. Je reconnais qu'ils sont partie intégrante du projet, mais cela ne signifie pas forcement qu'ils appartiennent à la même place que le code source.
    • .. Que voulez-vous dire "bon" versioning de contenu binaire? Chaque système que j'ai utilisé au cours des 20 dernières années m'a permis de vérifier dans les fichiers binaires. Bien sûr, CVS a été un peu capricieux, mais ces jours-ci git est parfait-- en fait, git traite tout le contenu binaire des objets blob (au moins à la couche de stockage). Que suis-je/nous manque?
    • Je suis d'accord avec @npd - tout Simplement parce que les fichiers binaires ne sont pas faciles à diff/version, ligne par ligne, ne signifie pas qu'ils doivent être exclus du contrôle de version. Il semble idiot de "jeter le bébé avec l'eau du bain'.
    • Hm, encore un autre de mes ans les choses dont je ne suis pas d'accord avec moi-même à ce point 🙂 Réponses vieillir, je suppose.
    • alors s'il vous plaît modifier votre réponse.
    • Bien que m'obligerait un ensemble beaucoup plus d'efforts pour fait état de mon avis sur la question à ce point qui permettrait d'orienter la réponse à l'écart de ce qui a été demandé. Je comprends le dilemme bien, devrions-nous avoir une réponse dépassée, ce qui n'est pas le même que très upvoted à une vieille question ou une mise à jour de la réponse à une question aussi ancienne que ne sera jamais une grande partie de l'auditoire, car il est le dernier sur les réponses et les gens ont appris à très impatient et ne faites défiler tout le chemin vers le bas plus. J'admets être un peu paresseux sur la mise à jour de ce trop, pas de question à ce sujet.

    InformationsquelleAutor Esko
  4. 9

    Son Maven convention.

    Maven est basé sur Convention over configuration paradigme. C'est signifie: si vous ne suivez cette convention, vous devez configurer les sources sont situées. C'est le principal avantage à mon humble avis.

    • Ils dire Maven est fondé sur la convention over configuration, mais pourquoi les pom.xml:s d'un milliard de lignes de long et qu'est-ce que tout cela XML complexes en général...? 🙂
    • Vous êtes de droite. Mais pour sûr, si vous ne faites pas de l' /src/main/java que votre dossier source, votre pom.xml aura un milliard de dollars et un lignes 🙂
    • C'est vrai si vous utilisez maven, mais Eclipse etc. peut lire et créer un projet avec l'utilisateur, de la convention des droits de l'amende juste.
    • Je pense que tu as mal...alors. C'est convention over configuration. Ce n'est pas n la configuration de la configuration. Je considère que le déclaratif, au lieu de l'impératif, de la nature des Pdm un pur génie concept. XML est verbeux, d'accord. Mais avec ce que le contenu est lisible et compréhensible. Nous avons commencé à s'abstenir d'utiliser des identificateurs comme a, a1, a2, x, y, z il y a longtemps, n'est-ce pas?
    InformationsquelleAutor sourcerebels
  5. 4

    Oui, c'est une maven convention, mais même si vous n'êtes pas à l'aide de maven, il y a des avantages à l'utiliser:

    1. les gens à nouveau le projet aura un temps plus facile de venir jusqu'à la vitesse, puisque c'est un "standard"
    2. la présente convention est flexible et a une place pour les non-code Java et d'autres choses que vous n'avez pas à ce point. C'est la raison pour laquelle il est populaire et vous pouvez trouver qu'il évolue de mieux qu'un régime, vous venez avec votre propre
    3. si vous voulez vous déplacer à maven à un certain point, il sera facile

    Bien que je ne discute pas, il faut passer à chaque changement, lors du démarrage d'un nouveau projet, il n'y a vraiment aucune raison de ne pas l'utiliser, sauf si vous êtes en désaccord philosophique avec la façon dont il se casse le code.

    InformationsquelleAutor ndp