pom - Organización de carpetas de proyectos Java Eclipse

estructura de un proyecto en java

Question

Estoy llegando a Java y Eclipse desde un fondo de C # / Visual Studio. En este último, normalmente organizaría una solución como esta:

/ MyProjects / MyApp / MyAppsUtilities / LowerLevelStuff

donde MyApp contendría un proyecto para compilar un archivo .exe, MyAppsUtilities creará una DLL de ensamblaje llamada por el archivo .exe, y LowerLevelStuff probablemente compilará un ensamblaje que contenga clases utilizadas por la DLL de utilidades de nivel superior.

En Eclipse (Ganimedes, pero podría ser convencido de cambiar a Galileo) tengo:

/ MyProjects / workspace / MyApp

Cuando creo mi proyecto inicial. Hay una opción para colocar los archivos de origen y de compilación en la misma carpeta, pero tengo archivos .java creados en una ruta que refleja la jerarquía de mi paquete:

/ MyProjects / workspace / MyApp / src / com / mycompany / myapp / MyApp.java

Mi pregunta es la siguiente: cuando creo subproyectos (¿es el término Java / Eclipse correcto?) Para archivos .jar que serán análogos a los archivos DLL de ensamblaje MyAppsUtilities y LowerLevelStuff anteriores en .NET, ¿puedo (debería) organizar las carpetas de manera equivalente? P.ej:

/ MyProjects / workspace / MyApp / src / com / mycompany / myapp / myapputilities / MyAppsUtilities.java

¿Cuál es la manera estándar / correcta de organizar estas cosas y cómo se hace específicamente en el IDE?

Answer 1

Hay dos cosas que debe aclarar antes de poder responder a esta pregunta:

1. ¿Qué repositorio de código fuente usará?
2. ¿Qué sistema de compilación utilizará para construir automáticamente artefactos fuera de Eclipse?

Las respuestas influirán fuertemente en sus opciones.

Hemos optado por "un componente de proyecto de Eclipse pr", que puede ser una biblioteca o un archivo ejecutable / ejecutable terminado. Esto ha facilitado la automatización con Hudson. Nuestro uso de CVS también es más fácil, ya que los proyectos individuales no tienen múltiples responsabilidades.

Tenga en cuenta que cada proyecto puede contener varias carpetas de origen que separan, por ejemplo, el código de prueba de la configuración de la fuente de Java. Eso no es tan importante como simplificar su estructura.

Answer 2

Maven tiene un diseño de directorio estándar bien pensado. Incluso si no lo está utilizando directamente, puede pensar en esto como un estándar de facto. Los proyectos de "módulo múltiple" de Maven son una analogía justa con el diseño de ensamblaje múltiple .net que usted describió.

Answer 3

Normalmente, crearía proyectos relacionados o subproyectos como proyectos diferentes en Eclipse.

Answer 4

Piense en los paquetes de código fuente de Java como un gran espacio de nombres jerárquico. Las aplicaciones comerciales generalmente viven en '' com.mycompany.myapp '' (el sitio web para esta aplicación podría ser '' http://myapp.mycompany.com '', aunque obviamente este no es siempre el caso).

Cómo organizar las cosas bajo su paquete myapp depende en gran medida de usted. La distinción que hace para C # entre ejecutables (.exe), DLL y clases de bajo nivel no existe en la misma forma en Java. Todo el código fuente de Java se compila en archivos .class (cuyo contenido se llama ''bytecode'') que puede ser ejecutado por una Máquina Virtual de Java (JVM) en muchas plataformas. Por lo tanto, no hay una distinción inherente en las clases de alto / bajo nivel, a menos que usted atribuya dichos niveles a través de su paquete. Una forma común de envasado es:

• com.mycompany.myapp : clase principal; MyApp (con un método principal)
• com.mycompany.myapp.model : clases de modelo de dominio; Cliente, Pedido, etc.
• com.mycompany.myapp.ui : código de interfaz de usuario (presentación o vista)
• com.mycompany.myapp.service : servicios dentro de su aplicación, es decir, ''lógica empresarial''
• com.mycompany.myapp.util : clases de ayuda utilizadas en varios lugares

esto sugiere una aplicación Java independiente, podría ser diferente si se trata de una aplicación web que usa uno de los muchos marcos.

Estos paquetes corresponden a una jerarquía de directorios en su proyecto. Cuando se utiliza Eclipse, la raíz de dicha jerarquía se denomina "directorio de origen". Un proyecto puede definir múltiples directorios de origen, comúnmente un directorio de origen ''principal'' y un ''test''.

Ejemplo de archivos en su proyecto:

src/test/java/com/acme/foo/BarTest.java
src/main/java/com/acme/foo/Bar.java
lib/utilities_1_0.jar

Y dentro de utilities_1_0.jar:

com/acme/foo/BarUtils.class

BarUtils.class es una clase java compilada, por lo tanto, en forma de código de bytes independiente de la plataforma que se puede ejecutar en cualquier JVM. Por lo general, los archivos jar solo contienen las clases compiladas, aunque a veces se puede descargar una versión del archivo jar que también contiene los archivos de origen (.java). Esto es útil si desea poder leer el código fuente original de un archivo jar que está utilizando.

En el ejemplo anterior, Bar, BarTest y BarUtils están todos en el mismo paquete com.acme.foo pero residen físicamente en diferentes ubicaciones en su disco duro.

Las clases que residen directamente en un directorio de origen están en el ''paquete predeterminado'', por lo general no es una buena idea mantener las clases allí porque no está claro a qué compañía y aplicación pertenece la clase y puede obtener conflictos de nombre si hay algún archivo jar que agrega a su ruta de clase contiene una clase con el mismo nombre en el paquete predeterminado.

Ahora, si implementa esta aplicación, normalmente se compilaría en archivos .class y se agruparía en un .jar (que es básicamente un nombre elegante para un archivo .zip más información de manifiesto). Hacer un archivo .jar no es necesario para ejecutar la aplicación, pero es útil para implementar / distribuir su aplicación. Usando la información del manifiesto, puede hacer que un archivo .jar sea ''ejecutable'', de modo que un usuario pueda ejecutarlo fácilmente, vea [a].

Por lo general, también utilizará varias bibliotecas, es decir, los archivos .jar existentes que obtuvo de Internet. Algunos ejemplos muy comunes son log4j (un marco de registro) o bibliotecas JDBC para acceder a una base de datos, etc. También puede tener sus propios submódulos que se implementan en archivos jar separados (como ''utilities_1_0.jar'' arriba). La forma en que se dividen las cosas en archivos comprimidos es una cuestión de implementación / distribución, todavía comparten el espacio de nombres universal para el código fuente de Java. Entonces, en efecto, podría descomprimir todos los archivos jar y colocar los contenidos en una gran estructura de directorios si quisiera (pero generalmente no).

Al ejecutar una aplicación Java que utiliza / consiste en múltiples bibliotecas, se encuentra con lo que comúnmente se conoce como ''Classpath hell''. Uno de los mayores inconvenientes de Java como lo conocemos. (nota: la ayuda está supuestamente en camino ). Para ejecutar una aplicación Java en la línea de comandos (es decir, no desde Eclipse), debe especificar cada ubicación de archivo .jar en la ruta de clase. Cuando está utilizando uno de los muchos marcos de Java (Maven, Spring, OSGi, Gradle), suele haber algún tipo de soporte para aliviar este dolor. Si está creando una aplicación web, generalmente solo tendrá que adherirse a sus convenciones de capas / implementación para poder desplegar fácilmente la cosa en el contenedor web de su elección (Tomcat, Jetty, Glassfish).

¡Espero que esto dé una idea general de cómo funcionan las cosas en Java!

[a] Para hacer un jar ejecutable de la aplicación MyApp, necesitas un JDK en tu ruta. Luego use la siguiente línea de comando en su directorio de compilación (bin o target):

jar cvfe myapp.jar com.mycompany.myapp.MyApp com/mycompany/myapp

A continuación, puede ejecutarlo desde la línea de comandos con:

java -jar myapp.jar

o haciendo doble clic en el archivo jar. Tenga en cuenta que no verá la consola de Java en ese caso, por lo que esto solo es útil para las aplicaciones que tienen su propia GUI (como una aplicación de Swing) o que puede ejecutarse en segundo plano (como un servidor de socket).