2010-11-11 4 views
5

Wir haben ein Problem an dem Ort, an dem ich mit der Referenzierung mehrerer Projekte in unserem Code arbeite. Grundsätzlich haben wir ein Produkt, das ich Leviathan nennen werde. Dieses Projekt hat eine ganze Reihe anderer Versionen, von denen jede einzelne in Eclipse als separate Projekte verwaltet wird. Als Entwickler haben wir normalerweise mehrere Projekte (mehrere Versionen) gleichzeitig in Eclipse geöffnet, da wir Helpline-Aufrufe über ältere Versionen erhalten (und gleichzeitig mehrere Versionen entwickeln).Wie kann ich Bibliotheken in einem anderen Projekt innerhalb von Eclipse Helios referenzieren?

Wir haben auch Testcode, der in einem anderen Projekt für jede Verteilung von Leviathan ist. Ich benenne meine Projekte Leviathan_<branch name>. So zum Beispiel in meinem Eclipse-Workspace, könnte ich habe Projekte wie:

 
Leviathan_scott\ (my branch) 
Leviathan_9.2\ 
Leviathan_9.3\ 
Leviathan_10.0\ 
Leviathan_10.1\ 
Test_scott\ 
Test_10.0 

Mein Zweig ist eine Kopie unseres Stammes, so können wir, dass die aktivste Entwicklungslinie betrachten.

Das Problem ist, dass wir einige Bibliotheken in Leviathan \ lib in unserem Testcode verweisen. Jeder Entwickler kann seine Projekte leicht anders benennen. Wenn wir also den .classpath des Testprojekts entwickeln, verweisen wir auf das Projekt Leviathan \ (keine Zusätze). Der Classpath für dieses Projekt (die in unser Quellkontrollsystem überprüft wird) könnte wie folgt aussehen:

<?xml version="1.0" encoding="UTF-8"?> 
<classpath> 
    <classpathentry excluding="**/*.MySCMServerInfo" kind="src" path="src"/> 
    <classpathentry kind="lib" path="lib/abbot-1.0.2/abbot.jar"/> 
    <classpathentry kind="lib" path="lib/abbot-1.0.2/costello.jar"/> 
    <classpathentry kind="lib" path="lib/dbunit-2.4.8/dbunit-2.4.8.jar"/> 
    <classpathentry kind="lib" path="lib/easymock-3.0/easymock-3.0.jar" sourcepath="lib/easymock-3.0/easymock-3.0-sources.jar"> 
     <attributes> 
      <attribute name="javadoc_location" value="jar:platform:/resource/Test/lib/easymock-3.0/easymock-3.0-javadoc.jar!/"/> 
     </attributes> 
    </classpathentry> 
    <classpathentry kind="lib" path="lib/objenesis-1.2/objenesis-1.2.jar"/> 
    <classpathentry kind="lib" path="lib/privilegedAccessor-1.0.2/privilegedAccessor_1.0.2.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-core/unitils-core-3.1.jar" sourcepath="lib/unitils-3.1/unitils-core/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-database/unitils-database-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-dbmaintainer/unitils-dbmaintainer-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-dbunit/unitils-dbunit-3.1.jar" sourcepath="lib/unitils-3.1/unitils-dbunit/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-inject/unitils-inject-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-mock/unitils-mock-3.1.jar" sourcepath="lib/unitils-3.1/unitils-mock/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-orm/unitils-orm-3.1.jar"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-spring/unitils-spring-3.1.jar" sourcepath="lib/unitils-3.1/unitils-spring/src"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-testng/unitils-testng-3.1.jar" sourcepath="lib/unitils-3.1/unitils-testng/src"/> 
    <classpathentry kind="lib" path="data"/> 
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> 
    <classpathentry kind="lib" path="lib/unitils-3.1/unitils-core/lib/ognl-2.6.9.jar"/> 
    <classpathentry kind="lib" path="lib/testng-5.14.1/testng-5.14.1.jar" sourcepath="lib/testng-5.14.1/testng-5.14.1-src.zip"/> 
    <classpathentry combineaccessrules="false" kind="src" path="/Leviathan"/> 
    <classpathentry kind="lib" path="/Leviathan/lib/slf4j-api-1.6.1.jar"/> 
    <classpathentry kind="lib" path="/Leviathan/lib/hibernate3.jar" sourcepath="/Leviathan/lib/src/hibernate-3.6.0-src.zip"/> 
    <classpathentry kind="output" path="classes"/> 
</classpath> 

Wenn ein Entwickler das Testprojekt in ihrem/seinen einzelnen Eclipse-Workspace lädt, würde er/sie brauchen um das Projekt zu verknüpfen zu dem ursprünglichen Leviathan-Projekt, indem Sie zu Präferenz-> Java-Build-Pfad-> Projekte gehen und das Leviathan_scott-Projekt hinzufügen.

Die Sache ist, das ändert natürlich keinen der <classpathentry ... > Einträge, die sich auf "Leviathan \ lib" beziehen. Also, wir haben eine von zwei Dinge zu tun:

  1. ändern alle Referenzen von Leviathan zu Leviathan_<branch name> in meinem .classpath einen Texteditor finden mit/ersetzen.
  2. Entfernen Sie alle Verweise auf Leviathan * .jar in Java Build Path und fügen Sie die Jars in Leviathan_scott * .jar erneut hinzu.

Das Problem dabei ist, dass es jedes Mal getan werden muss die .classpath geändert wird, was beides macht scheinen weniger als ideal. Unser Klassenpfad wird nicht super-regelmäßig geändert, aber ich würde sagen, dass es alle zwei Wochen ein- oder zweimal geändert wird. Ich möchte mein Projekt verknüpfen können und nur einen einzigen Schritt ausführen, um diese Projekte zu verknüpfen.

Es scheint, als könnten wir eine Umgebungsvariable innerhalb von Eclipse einrichten und diese in die .classpath-Einträge einfügen. Aber jetzt haben wir ein Problem, denn wenn wir mehrere Testprojekte in unserem Arbeitsbereich haben, die wir kompilieren wollen, wird das nicht funktionieren. Die beiden Einträge des .classpath-Testprojekts beziehen sich auf die gleiche Umgebungsvariable, die natürlich nur auf einen Superprojektstandort verweisen kann.

Es scheint, als ob ich in der Lage, dies zu tun, aber ich weiß nicht genau, wie es in Eclipse zu erreichen. Irgendwelche Gedanken würden sehr geschätzt werden.

~ Scott

+0

Apache Maven sortiert diese Art von Problemen wie ein Zauber aus. –

+0

Einverstanden, aber es ist schwierig, 20 Entwickler dazu zu bringen, auf ein neues Build-System umzusteigen ... Wenn wir * unbedingt * müssen, könnte ich vielleicht dafür argumentieren, aber wenn es möglich ist, ohne dies auszukommen, dann ich würde es gerne so machen. – jwir3

Antwort

2

Versuchen Sie es mit 'Klassenpfadvariablen' von Eclipse.

Window->Preferences->Java->Build Path->Classpath Variables 

definieren eine oder mehrere Variablen wie „Leviathan_under_test“ und verweisen Sie auf die Version, die Sie testen möchten. Ändern Sie dann im Build-Pfad des Projekts die Bibliotheksreferenz so, dass sie die Variable enthält.

Wenn Sie die Version von Leviathan, die Sie testen möchten, ändern, ändern Sie die Variable und gehen. Wenn Sie müssen, können Sie sogar mehrere Variablen für Versionen haben, die häufiger getestet werden, z. B. "LEVIATHAN_LATEST" ODER "LEVIATHAN_PROBLEM_CHILD" usw.

+0

Nun, das habe ich gemeint, wenn ich über Umgebungsvariablen gesprochen habe. Das Problem hier ist also, dass ich den Build - Pfad noch ändern muss - wenn ich zum Beispiel Test_10.0 und Test_scott herunterladen und sie im selben Arbeitsbereich kompilieren wollte, müsste ich die Variable in der ändern .classpath-Datei in mindestens einem der beiden Test-Projekte. Im Idealfall möchten wir dies vermeiden, weil es nicht wirklich besser ist als das, was wir gerade haben - Leviathan zu Leviathan_scott oder etwas Ähnlichem ändern zu müssen. – jwir3

+0

Wenn die Variable tatsächlich in der Datei .classpath ist, ändern Sie sie nicht; zumindest im Fall von $ LEVIATHAN zum Beispiel. Der Build arbeitet mit dem Klassenpfadvariablenwert, den Sie in Ihrem Arbeitsbereich festgelegt haben. Sie können auf ein anderes Ziel verweisen, ohne Dateien in Ihrem Projekt bearbeiten zu müssen. –

+0

Nun, nicht ganz. Wie würde ich das Problem lösen, bei dem Leviathan_10.0, Leviathan_Test_10, Leviathan_scott und Leviathan_test_scott in meinem Arbeitsbereich alle gleichzeitig geöffnet sind und ich möchte, dass Leviathan_test_scott auf Leviathan_scott und Leviathan_test_10 auf Leviathan_10.0 zeigt? – jwir3

2

Dies ist ein Abhängigkeitsmanagement Problem und es gibt viele de-facto-Standard-Tools zu helfen! Ich schlage vor, Sie verwenden ANT mit Ivy's Abhängigkeitsverwaltung oder verwenden Sie Maven (oder jedes andere Build-Tool, das Abhängigkeitsverwaltung hat).

Mit beiden würde ich ein Artefakt Repository Maanger wie Nexus oder Artifactory auch verwenden, so dass Sie die eine wahre Quelle für Ihre intern gebauten Artefakte haben.

Auf diese Weise haben Sie immer die kanonische Version der Bibliothek, die Sie wollen, wenn Sie es wollen.

1

Wenn Sie keine externen Tools verwenden möchten, um die verschiedenen Projektabhängigkeiten zu verwalten, können Sie versuchen, auf der Registerkarte Auftrag und Export zu den einzelnen Leviathan-Projekten Pfadpfadeigenschaft zu gehen und die Bibliotheken zu überprüfen Tests. auf diese Weise müssen Sie die Bibliotheken nicht in das Testprojekt importieren, und indem Sie das zu testende Projekt wechseln, aktualisieren Sie automatisch die Bibliotheken

+0

Hm ... das sieht vielversprechend aus. Also, anstatt alle Bibliotheken einzeln innerhalb eines Testprojektes zu importieren, exportieren sie diese aus dem ursprünglichen Leviathan-Projekt, dann muss ich nur das Leviathan-Projekt in das Testprojekt importieren? – jwir3

+0

ja, das sollte funktionieren – pbanfi

Verwandte Themen