¿Cuántos proyectos múltiples de Eclipse se consideran demasiado excesivos para un proyecto de desarrollo real?

Question

Actualmente estoy trabajando en un proyecto que contiene muchos proyectos diferentes de Eclipse que se referencian entre sí para formar un gran proyecto. ¿Hay algún punto en el que un desarrollador deba preguntarse si debería replantearse la estructura de su proyecto de desarrollo?

NOTA: Mi proyecto actualmente contiene más de 25 proyectos diferentes de Eclipse.

Answer 1

Mi regla general es crear un nuevo proyecto para cada componente reutilizable. Entonces, por ejemplo, si tengo alguna funcionalidad aislada que pueda empaquetarse, por ejemplo, como jar, crearía un nuevo proyecto para poder compilar, distribuir y distribuir el componente de manera independiente.

Además, si hay ciertos proyectos en los que no necesita realizar cambios frecuentes, puede compilarlos solo cuando sea necesario y mantenerlos "cerrados" en eclipse para ahorrar tiempo en la indexación, etc. Incluso si piensa que un cierto componente no es reutilizable, siempre que esté separado del resto de la base de código en términos de lógica/preocupaciones, puede ser útil simplemente separándolo. A veces, el código aparentemente específico puede ser reutilizable en otro proyecto o en una versión futura del mismo proyecto.

Answer 2

En un trabajo anterior, toda la aplicación era más de +170 proyectos. Si bien rara vez fue necesario realizar todos los proyectos de forma local, incluso los 30-40 proyectos constantemente en nuestro alcance hicieron que la reindexación, etc., fuera muy lenta.

Answer 3

Yeesh. Un proyecto para cada proyecto. Si está utilizando proyectos reutilizables, conviértalos en una biblioteca por el amor de Dios. Rompe los proyectos no reutilizables en paquetes, para eso están ahí.

Answer 4

Cree tarros para los proyectos con los que no trabaja a menudo. Eso debería reducir en gran medida el desorden. Si trabaja en todos los proyectos a menudo, puede agregar objetivos a su compilación que le afecten los respectivos proyectos, que lo condensa todo en un archivo que luego puede incluir en la ruta de la clase.

Answer 5

Cuando se compila, un proyecto suele dar como resultado un jar. Entonces, si su aplicación consiste en componentes potencialmente reutilizables, está bien usar un proyecto para cada uno.

Soy un gran fan de usar muchos proyectos, siento que esto "descompone" grandes cosas más allá de lo que puedo hacer con los paquetes, y me ayuda a orientarme y navegar.

Por supuesto, si está desarrollando complementos Eclipse, todo sería un proyecto de todos modos.

Lo único que debería tener en cuenta es el control de origen y la capacidad de manejar movimientos de archivos entre proyectos. Subclipse me había estado causando problemas, o tal vez es mi servidor SVN el que lo hizo.

Answer 6

Si su proyecto tiene que muchos subproyectos, o módulos, se necesitan para componer su artefacto final, entonces es hora de considerar tener algo como Maven y configurar un proyecto de varios módulos. Le permitirá a) trabajar en cada módulo de forma independiente sin preocupaciones y permitir una fácil configuración en su ide (y en otros IDEs) a través del objetivo mvn eclipse:eclipse. Además, al construir todo su proyecto de nivel superior, maven podrá derivar de la lista de dependencias que ha descrito qué módulos deben construirse en qué orden.

Here's a quick link via google y un l ink to the book Maven: The Definitive Guide, que explicará las cosas con mucho más detalle en el capítulo 6 (una vez que tenga los conceptos básicos).

Esto también forzará a su proyecto a no estar explícitamente vinculado a Eclipse. Poder construir independientemente de una ide significa que cualquier Joe Schmoe puede venir y trabajar fácilmente con su base de código usando las herramientas que necesite.

Answer 7

Demonios, tenemos más de 100. Los proyectos no cuestan nada.

Answer 8

Un método adicional es crear muchos espacios de trabajo diferentes. El beneficio de los espacios de trabajo separados es que puede eliminar parte del desorden visual/desempeño general de tener muchos proyectos. Puede usar objetivos para sacudir todos sus proyectos y colocarlos en un repositorio para que pueda referenciarlos en cada espacio de trabajo.

Answer 9

Esa es una pregunta difícil y las respuestas abarcan desde tener un proyecto de eclipse hasta tener un proyecto de eclipse para cada clase.

Mi línea de fondo:

1. Puede tener muy pocos proyectos, y no demasiados (por supuesto usan automatización por ejemplo MVN Eclipse: Eclipse)
2. Uso -Declipse.useProjectReferences = verdadero/falso cuando se utiliza Maven para cambiar el modo de espacio de trabajo por cierto frasco y proyectos dependencias
complemento
3. uso liberación MVN para generar lanzamientos consecutivos (automa tic aumento versión )
4. Múltiples proyectos le da versiones independiente que es extremadamente importante. P.ej. un desarrollador puede trabajar en una nueva versión de un módulo mientras aún depende de el anterior y usted en algún punto decide actualizar a la versión más reciente (posiblemente aumentando su versión en la sección de dependencia pom.xml). O en otro caso, si un proyecto contiene un error, degrada el a su versión anterior.
5. Múltiples proyectos te hace pensar sobre la arquitectura más que si tienes solo paquetes.
6. Los proyectos múltiples en general hacen que problemas arquitectónicos sean más evidentes que que si solo tiene un proyecto. ¿Alguien quiere comentar sobre esto?
7. Nunca se sabe si proyecta evoluciona a OSGI/SOA/EDA donde necesita separación.
8. Incluso si estás 100% seguro de que proyectos serán desplegados como un frasco de una forma de edad en una única JVM, que todavía no se pierde nada (MVN montaje plug-in) para tener múltiples eclipses proyectos para lógicamente independiente piezas de código

Por cierto, el proyecto en el que trabajo está dividido en 24 proyectos de eclipse.