Comment organisez-vous les ressources non sources disponibles sur le chemin de classe dans votre projet java?

Question

Dans un projet de logiciel écrit en java, vous avez souvent des ressources qui font partie du projet et doivent être incluses dans le chemin de classe. Par exemple, certains modèles ou images devraient être accessibles via le classpath (getResource). Ces fichiers doivent être inclus dans un fichier JAR produit.

Il est clair que ces ressources doivent être ajoutées au système revision-control-control. Mais dans quel répertoire vous mettez ces fichiers? Parallèlement aux fichiers source Java ou dans un autre répertoire qui reproduit également la structure de package requise?

Answer 1

Je préfère votre dernière solution: un répertoire distinct qui imite la structure de package du code source & # 8217; De cette façon, ils ne & # 8217; t obscurciront pas votre code source mais seront juste à côté des fichiers de classe compilés dans le fichier JAR empaqueté.

Answer 2

Maven les place dans src / main / resources / (le code Java irait dans src / main / Java/). La raison principale en est que Maven peut compiler du code dans différentes langues et qu'il est logique de les séparer pour éviter que les fichiers ne soient confondus.

Dans le cas de ressources, Maven remplacera les variables avant leur ajout dans un fichier Jar, elles seront donc & "compilées &"; sources aussi.

Answer 3

Personnellement, je préférerais les associer au code source s’ils sont fortement liés à des parties spécifiques du code et s’ils ne sont pas trop nombreux.

Mais s'il est logique que ces fichiers aient leur propre structure d'organisation, ou s'il existe des centaines de fichiers qui rendraient difficile la recherche du code source parmi eux, je les garderais séparément.

Answer 4

Cela dépend de vos préférences. Leur mélange avec les fichiers de code source facilite les refactorisations telles que le changement de nom de packages (les ressources étant déplacées avec les sources), mais avec plus d’une poignée d’icônes, d’images et de fichiers de localisation, vous obtenez très facilement un fouillis de fichiers.

Avec les outils actuels, cela n'a pas vraiment d'importance. Que vous utilisiez Eclipse, Netbeans ou un autre outil, ils vous permettent tous d’avoir des packages binaires avec une présentation différente de celle du code source. En fin de compte, vous pouvez le faire comme vous le souhaitez.

Personnellement, j'essaie d'éviter de mélanger le code source avec les ressources, car je ne les modifie généralement que très rarement, mais le code source très fréquemment.

Answer 5

Je vais généralement comme ça:

project/src
project/resources
project/classes
project/lib
project/dist

src et les ressources ont la structure du package et le fichier de construction prennent les classes et les ressources en tant qu'entrée pour le pot qui est placé dans dist .

Lors de l'exécution en interne, le chemin d'accès aux classes a quelque chose comme: lib; classes; ressources;

Si l'application dispose d'une installation, le programme d'installation crée et place le répertoire de ressources intact dans l'installation.

Answer 6

Vous pouvez mettre ces éléments dans le chemin de classe si votre outil de génération n’a pas été confondu. Eclipse n'essaiera pas de compiler vos fichiers JPEG et Ant ne le fera pas non plus, il n'y a donc pas grand chose à craindre. La bonne chose est que si vous avez beaucoup de choses liées, vous pouvez les garder ensemble, organisées par fonctionnalité plutôt que par type de fichier.

Nous faisons cela où je travaille; nous avons des messages électroniques qui nécessitent un peu de code et une poignée de ressources statiques. Toutes ces choses sont conservées ensemble dans un dossier du chemin source java; nous pouvons facilement ajouter et supprimer un email du système, sans oublier des choses ou faire des erreurs telles que des chemins src / ressources incompatibles ou des fichiers orphelins dans une arborescence non présente dans une autre arborescence.

Answer 7

Comme déjà dit, à vous de choisir et peut varier d’un projet à l’autre. Par exemple, avec Wicket , il est tout à fait normal et pratique de conserver .html des fichiers à proximité des classes. De plus, je garde souvent certaines configurations avec le code source - META-INF, WEB-INF, journalisation.

Pour que Maven utilise des ressources de l'arborescence source, utilisez ceci:

<build>
   <resources>
     <resource>
         <directory>src/main/resources</directory>
     </resource>
     <!-- Web - Wicket -->
     <resource>
         <filtering>false</filtering>
         <directory>src/main/java</directory>
         <includes><include>**</include></includes>
         <excludes><exclude>**/*.java</exclude></excludes>
     </resource>
  </resources>

  <testResources>
     <testResource>
         <directory>src/test/resources</directory>
     </testResource>
     <!-- Web - Wicket -->
     <testResource>
         <filtering>false</filtering>
         <directory>src/main/java</directory>
         <includes><include>**</include></includes>
         <excludes><exclude>**/*.java</exclude></excludes>
     </testResource>
  </testResources>

La principale raison de garder les ressources séparées est la séparation (imho) des rôles de travail. Par exemple. si vous avez un projet avec des équipes de traduction, vous devez conserver les ressources avec des chaînes séparées du code et avec des privilèges SCM différents.