# Ordner in Eclipse-Classpath angeben



## AMiGA (29. Okt 2009)

Hallo,

ich habe folgendes Problem: Ich habe zwei Projekte. Ein Projekt enthält Basis-Code, der immer wieder genutzt wird, das andere Projekt den projektspezifischen Code. Ich checke nun das Projekt1 (projektspezifischer Code) aus dem CVS aus. Nun checke ich das Projekt2 (mit dem Basis-Code) aus dem CVS aus und zwar in (!) mein Projekt1.

Projekt2 enthält jede Menge jarfiles. Ich muss nun derzeit hingehen und diese jarfiles alle manuell in den Classpath (es geht nur um Eclipse!) eintragen. Wenn ich nun jarfiles in Projekt2 entferne/hinzufüge, muss ich den Classpath sämtlicher auf Projekt2 basierenden Projekte (bei allen Entwicklern) anpassen. Das würde ich gerne vermeiden.

Gibt es eine Möglichkeit, im Eclipse-Classpath (.classpath) einen ganzen Ordner mit jarfiles anzugeben? Dann könnte ich dort Projekt2\jars angeben und müsste nichts weiter anpassen.

Gruß,
AMiGA


----------



## Wildcard (29. Okt 2009)

AMiGA hat gesagt.:


> Nun checke ich das Projekt2 (mit dem Basis-Code) aus dem CVS aus und zwar in (!) mein Projekt1.


Warum machst du das so? Warum siehst du Projekt2 nicht als Artefakt das von Projekt1 benötigt wird?


----------



## AMiGA (30. Okt 2009)

> Warum machst du das so? Warum siehst du Projekt2 nicht als Artefakt das von Projekt1 benötigt wird?


Du meinst warum ich Projekt2 nicht separat auschecke und in Projekt1 referenziere?

Zum einen ist es deutlich übersichtlicher, wenn Projekt2 innerhalb von Projekt1 liegt. Wenn ich x verschiedene Projekte hätte und alle jeweils (einen bestimmten Branch von) Projekt1 referenzieren, würde es ziemlich schnell unübersichtlich.

Zum anderen ließe sich Projekt2 sowieso nicht eigenständig (vollständig) kompilieren oder ausführen, daher wäre ein eigenständiges Auschecken nicht wirklich vorteilhaft.

Ich hatte meine ursprüngliche Beschreibung schon vereinfacht. Eigentlich werden sogar noch mehr Projekte in Projekt1 ausgecheckt. So ist unsere Softwarestruktur derzeit aufgebaut: Wir haben mehrere Basis-Module, auf denen aktuelle Projekte immer basieren (diese Basis wird stetig weiterentwickelt, so profitieren neue Projekte automatisch davon). Das neue Projekt wird erzeugt und dann werden erst einmal die Module, die das Projekt benötigt, in das neue Projekt ausgecheckt.

Gruß,
AMiGA


----------



## maki (30. Okt 2009)

> Zum einen ist es deutlich übersichtlicher, wenn Projekt2 innerhalb von Projekt1 liegt. Wenn ich x verschiedene Projekte hätte und alle jeweils (einen bestimmten Branch von) Projekt1 referenzieren, würde es ziemlich schnell unübersichtlich.
> 
> Zum anderen ließe sich Projekt2 sowieso nicht eigenständig (vollständig) kompilieren oder ausführen, daher wäre ein eigenständiges Auschecken nicht wirklich vorteilhaft.


Das ist eigentlich der sauberste Weg, wird immer so praktiziert, so bleiben die Abhängigkeiten klar und die einzelnen Projekte sauber strukturiert.
Für die Depoendency Verwaltung inkl. Version (weil du von Branch gesprochen hast) gibt es doch genügend Tools, von Maven2, Ant+Ivy bis zu Buckmister..

Jedenfalls ist euer vorgehen unorthodox und unsauber.


----------



## AMiGA (30. Okt 2009)

> Jedenfalls ist euer vorgehen unorthodox und unsauber.


Aber ist es nicht nachvollziehbar?

Pro Jahr kommen im Schnitt vielleicht 3 Projekte hinzu. Für jedes Projekt habe ich dann in Eclipse einmal das Projekt selber und die (sagen wir mal 5) Module (jeweils den entsprechenden Branch) ausgecheckt. Das wird doch extrem unübersichtlich, oder nicht?

Gruß,
AMiGA


----------



## maki (30. Okt 2009)

> Aber ist es nicht nachvollziehbar?


Nein, merkst du das denn nicht schon selber?



> Pro Jahr kommen im Schnitt vielleicht 3 Projekte hinzu. Für jedes Projekt habe ich dann in Eclipse einmal das Projekt selber und die (sagen wir mal 5) Module (jeweils den entsprechenden Branch) ausgecheckt. Das wird doch extrem unübersichtlich, oder nicht?


Nein, wie gesagt, dafür gibt es Build Tools mit Dependency Management, wie oben erwähnt.


----------

