Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ich entwickle seit ca. 2 Monaten an einem J2EE-Legacyprojekt. Mit der Übernahme habe ich angefangen, ein Quelltextrepository in Form von SVN zu pflegen. Bisher war ich der einzige Entwickler an diesem Projekt. Jetzt muss jedoch jemand in der Urlaubsvertretung auf das Projekt zugreifen können.
Das Programm besitzt die von "Dynamic Web Project" in Eclipse vorgegebenen Spezialordner "src" (für die Java-Quellen) und "Webcontent" (für die JSPs).
In diesem Zusammenhang kommt es zu folgendem Problem:
Checkt mein Kollege dieses Projekt aus, so interpretiert Eclipse die Spezialordner als Teil des Packagenamens und beschwert sich bei allen Klassen, dass "src" nicht im Packagenamen (in der "package"-Deklaration) zu finden ist.
Ich habe eine Vermutung: Da sich das Projekt nicht als "Dynamic Web Project" importieren lässt (Es gibt nur "Check out this project in the workspace"), erscheint Eclipse die Verzeichnisstruktur wie bei einem Java-Projekt automatisch als Package. Das Auschecken als en neues Projekt über den Wizard funktioniert nicht, weil "Only available when the .project file does not exist in the repository". Meine Fragen sind mehrerlei:
1. Sollte ein .project File diese Informationen nicht beinhalten und der Checkout entsprechend in die "richtige" Projektart gehen?
2. Sollte ich, um das Problem zu lösen, die ".project"-Datei aus dem Repository löschen?
3. Kann ich Eclipse irgendwie beibringen, dass es sich bei "src" nicht um Teil des Packages handelt? Oder kann ich das ausgecheckte Projekt auf die Einstellungen von "Dynamic Web Project" umkonfigurieren?
4. Unter welchen Umständen ist das Einchecken von ".project" richtig?
Was imho jetzt noch fehlt ist ein Build Management, früher nahm man Ant, heute ist Maven2 verbreitet, aber auch Buckminster, Ivy etc. sind zu empfehlen, hauptsache nicht alles die IDE machen lassen.
Ach ja, dir fehlt jetzt wahrscheinlich noch die .classpath Datei im Repo, den die .project alleine reicht nicht (mit Buckminster/Ivy/Maven2 könntest du dir das sparen). Probleme wird es in deiner Konfig geben wenn nicht alle Jars bei allen Entwickler am selben Ort lagern, auch dieses Problem vermeidet man mit den oben vorgeschlagenen Alternativen.
Was imho jetzt noch fehlt ist ein Build Management, früher nahm man Ant, heute ist Maven2 verbreitet, aber auch Buckminster, Ivy etc. sind zu empfehlen, hauptsache nicht alles die IDE machen lassen.
Du hast Recht, die .classpath wird weder im Project Explorer angezeigt noch wird sie versioniert. Soll ich die Warnung "You have explicitly asked to version control one or more resources that otherwise would have been ignored. Continue?" in den Wind schlagen und diese einfach hinzufügen?
Probleme wird es in deiner Konfig geben wenn nicht alle Jars bei allen Entwickler am selben Ort lagern, auch dieses Problem vermeidet man mit den oben vorgeschlagenen Alternativen.
Ich schau' mir diese mal an. Derzeit ist eine Vergrößerung des Teams (bis auf die angesprochene Urlaubssituation) auch im Hinblick auf die Größe des Projektes eher unwahrscheinlich.
Danke, Maki, das hat geklappt. Das beschriebene Problem ist verschwunden, nachdem wir die .classpath Datei repliziert hatten. Ich hoffe, ich darf noch eine Frage anschließen:
Nach dem Checkout bei meinem Kollegen hat er scheinbar keine Klassen mehr gefunden, alle Importe wurden rot (und dann natürlich auch die entsprechenden Benutzungen der importierten Klassen). Normalerweise würde ich hier auf Pfade tippen, und ein Checkout auf meinem Computer unter einem anderen Projektnamen zeigt dieses Problem nicht. Ich kann allerdings im gesamten Projekt keine Referenz auf irgendwelche absoluten Verzeichnisse finden (eine Volltextsuche nach "dev" bei einem Workspace von d:\dev\workspace brachte keine Ergebnisse).
Aller Wahrscheinlichkeit nach läßt sich dieses Problem manuell lösen, aber unser Ziel wäre natürlich, dass ein neuer Entwickler einfach mittels Eclipse auschecken kann und gleich loslegen kann.
Sind das zufällig JEE Klassen (Servlet, ...) die nicht gefunden werden? Dann gibt es ein Problem mit der Server Runtime. Die ist wahrscheinlich bei Dir eingerichtet, wird aber nicht richtig eingecheckt und ist beim Kollegen fehlerhaft / nicht vorhanden.
Sind das zufällig JEE Klassen (Servlet, ...) die nicht gefunden werden? Dann gibt es ein Problem mit der Server Runtime. Die ist wahrscheinlich bei Dir eingerichtet, wird aber nicht richtig eingecheckt und ist beim Kollegen fehlerhaft / nicht vorhanden.
wenn der Checkout bei mir in ein Projekt mit einem neuen Namen funktioniert, kann es sich eigentlich nur noch um eine Eclipse-weite Konfiguration handeln.
Was er nicht findet, sind eigene Klassen. Ich habe eben auf Anhieb in den Bean-Statements Fehler gefunden sowie auch, dass beispielsweise "de" nicht aufgelöst werden konnte, was der erste Teil unserer Package-Hierarchie ist.
Solche Konfigurationen sollten immer mit einem neuen Projekt getestet werden, besser noch mit einem neuen Workspace, in letzterem werden Einstellungen gespeichert die so zscihen "Projekt weit" und "Eclipse weit" liegen, unter anderem auch die plugin KOnfigurationen.
Solche Konfigurationen sollten immer mit einem neuen Projekt getestet werden, besser noch mit einem neuen Workspace, in letzterem werden Einstellungen gespeichert die so zscihen "Projekt weit" und "Eclipse weit" liegen, unter anderem auch die plugin KOnfigurationen.
Brillianter Hinweis, vielen Dank Maki. Ein Checkout in einen neuen Workspace zeigt bei mir genau dasselbe Problem. Kann ich irgendwo nachlesen, welche Konfigurationen workspace-weit geteilt werden? Und ggf. auch, in welchen Dateien diese hinterliegen?
Da kann ich dir leider nicht sagen.. :bahnhof:
Vielleicht weiss Wildcard da mehr (und wenn er nicht, dann keiner )
Grundsätzlich ist es so, dass bei deiner manuellen Konfig immer manuell nachgearbeitet werden muss bis das ausgecheckte Projekt kompilierbar ist, mal mit mehr, mal mit weniger Aufwand, die von mir genannten Tools können dir das abnehmen, bin mir nicht sicher, denke aber das Buckminster da reichen würde, ansonsten wäre es nie verkehrt komplexere/umständlichere Konfigurationen als Entwickler Doku in einem Wiki zu hinterlegen, finde zB. DokuWiki ganz gut für so etwas.
Also das Dynamic Web Project aus meinem derzeitigen Projekt lässt sich problemlos Ein- und Auschecken, ohne das wir da manuell groß nachbessern mussten. Und wir benutzen kein Maven2 oder dergleichen.
Welches SVN Plugin benutzt Du eigentlich? Ich hoffe doch Subversive.
Das Problem ist doch offenbar, dass Subclipse in diesem Fall nicht alle nötigen Dateien comittet hat beim Sharen des Dynamic Web Project. Ich würde Dir dringend raten auf Subversive umzusteigen (das offizielle SVN Plugin von Eclipse).
Dann würde ich einfach das Projekt nochmal aus dem SVN schmeissen und mit Subversive erneut sharen. Bei mir funktioniert das wie gesagt problemlos. Ich kann aus einem neuen Workspace auschecken und habe keine Compilerfehler.
Eclipse kennt 3 verschiedene Preferences Scopes.
INSTALLATION - für die Applikation an sich, die Dateien werden irgendwo in eclipse/config, oder so abgelegt
INSTANCE - Workspace weit. Die Dateien liegen in WORKSPACE/.metadata/org.eclipse.resources
PROJECT - Preferences für ein Projekt. Die Dateien liegen in PROJECT/.prefs
Allerdings lässt sich von aussen immer schwer beurteilen welches PlugIn in welchem Scope welche Dateien ablegt, da würde nur nachschauen helfen.
Grundsätzlich ist es so, dass bei deiner manuellen Konfig immer manuell nachgearbeitet werden muss bis das ausgecheckte Projekt kompilierbar ist, mal mit mehr, mal mit weniger Aufwand, die von mir genannten Tools können dir das abnehmen, bin mir nicht sicher, denke aber das Buckminster da reichen würde
Wenn mit dem Projekt an sich etwas nicht stimmt (fehlende config), dann nicht. Wenn nur irgendwelche Abhängigkeiten fehlen weil sie Entwickler X mit lokalem Pfad angegeben hat, dann wäre das eine Aufgabe für Buckminster (oder eben Maven2/Ivy).
Maven2 und Ivy sind mächtige Tools, allerdings nach meiner Erfahrung sollten dann aber möglichst alle Projekte des Unternehmens auf diese Lösung setzen, sonst tut man sich nachher schwer Abhängigkeiten zu anderen Projekten aufzulösen.
Sollte in der Firma keine solch homogene Landschaft vorhanden sein, dann ist Buckminster definitiv einen Blick wert. Sauberes Dependency Management das sich aus vielen Unterschiedlichen Quellen bedient. Maven Repositories, Dateisystem, URLs, Subversion Repository, CVS, Archive,...
Ich kann dabei im Rahmen meiner Möglichkeiten gerne Hilfestellung geben, aber das hängt von den Anforderungen ab und was dir so vorschwebt.
Dann würde ich einfach das Projekt nochmal aus dem SVN schmeissen und mit Subversive erneut sharen. Bei mir funktioniert das wie gesagt problemlos. Ich kann aus einem neuen Workspace auschecken und habe keine Compilerfehler.
Hier habe ich einiges an Konfiguration gefunden. Leider liegen diese Dateien natürlich außerhalb des Projektordners und können nicht mit verteilt werden. Wäre das überhaupt ratsam bzw. möglich oder ist das bereits eine Vorstufe zu totalem Chaos?
Nein, diese Daten solltest du nicht mit anderen sharen.
Welche Fehler bekommst du jetzt genau wenn du das Projekt in einem frischen Workspace auscheckst und was musst du tun um es manuell zu korrigieren (vielleicht kommen wir der Sache so auf die Schliche).
leider werde ich die nächsten 2 Wochen urlaubsbedingt nicht im Büro sein und habe so keinen Zugriff auf den Stand. Ich werde den Thread aktualisieren, wenn ich wieder im Büro bin. Vielen Dank nochmals,
Nachdem ich jetzt zur Synchronisation mein Projekt weggeworfen und neu aus dem Repository ausgecheckt habe, sind nahezu alle Probleme weg. Nur eines bleibt: Es werden im Project Explorer Verzeichnisse mit Fehlern (rotes X) angezeigt, obwohl keiner der darunterliegenden Dateien einen Fehler aufweist (siehe angehängtes Bild).
In diesem Zusammenhang sei mir vielleicht die Frage noch erlaubt: Was ist dieser virtuelle "./"-Ordner und wie komme ich zu diesem? Als ich das Projekt übernommen habe, fehlte dieser definitiv, ich habe die Quellen immer unter "src" gefunden.
)
