Subversive erkennt Projekt nicht mehr nach Import via Ant

[TSH]

Hallo,

ich checke mein Projekt mit Subversive aus, lösche es direkt (ohne die Quellen zu löschen) und importiere als von der Ant-Datei wieder. So habe ich alle Pfade und Bibliotheken im Projekt. Das klappte mit Subclipse auch immer ganz gut. Jetzt benutze ich Subversive, und das erkennt nach dem Re-Import aus der Ant-Datei nicht mehr die .svn Infos :-(

Hat jemand da evtl. einen Tipp? Vor dem Löschen wurden die Infos ganz normal erkannt und ich konnte auch comitten usw.

 

[Wildcard]

ich checke mein Projekt mit Subversive aus, lösche es direkt (ohne die Quellen zu löschen) und importiere als von der Ant-Datei wieder. So habe ich alle Pfade und Bibliotheken im Projekt. Das klappte mit Subclipse auch immer ganz gut. Jetzt benutze ich Subversive, und das erkennt nach dem Re-Import aus der Ant-Datei nicht mehr die .svn Infos :-(

Wozu soll das denn gut sein? Hört sich ja sehr umständlich an ???:L

 

[TSH]

Am Projekt arbeiten auch Personen, die nicht Eclipse nutzen. Und "Import from Ant file" schien mir der einfachste Weg, Eclipse die richtigen Pfade mitzugeben. Blöde Idee?

 

[Wildcard]

Hmm, da gibt es mehrere Möglichkeiten, diese scheint mir am umständlichsten
Andere Möglichkeiten:
1. Du checkst das .project und .classpath File einfach ein, stört ja nicht wirklich
2. Du nimmst Maven
3. Du nimmst Buckminster
4. Du schreibst ein Ant-Script das du direkt als External Tool Builder ans Project hängst (dann müsste aber wieder .project eingecheckt werden)
5.ruf deinen Ant-Task doch einfach auf, warum erst löschen?

 

[TSH]

Danke für die Info. Wenn ich es nicht aus dem Ant importiere, sehe ich keine Klassenhierarchie im Java-View, sondern nur die Ordnerstruktur. Das ist nicht so schön.

Was wäre der Unterschied bei Maven oder Buckminster?

Generell denke ich eh über eine andere Lösung nach, weil ich das ganze gerne als Dynamic Web Project hätte.

Wären .project und .classpath sinnvoll, wenn 20 andere Personen mit unterschiedlichen Betriebssystemen gleichzeitig dran arbeiten?

 

[Wildcard]

Danke für die Info. Wenn ich es nicht aus dem Ant importiere, sehe ich keine Klassenhierarchie im Java-View, sondern nur die Ordnerstruktur. Das ist nicht so schön.

Vermutlich weil die .classpath fehlt. Würde nicht passieren wenn du die .classpath und .project mit eincheckst.

Was wäre der Unterschied bei Maven oder Buckminster?

Schwierig...
Maven ist ein mächtiges Werkzeug das dir viel abnimmt in bezug auf Dependency Resolution, Build, Paketierung, Workspace einrichten,...
Ist allerdings mehr eine Team Entscheidung als eine individuelle, denn mit Maven muss man den Maven weg gehen.

Buckminster ist nicht unbedingt selbst ein Build System, es kombiniert vielmehr unterschiedliche Ideen.
Ähnlich wie bei Maven geht Buckminster davon aus das es eine Component Cloud gibt. Als Entwickler (oder Build System) möchtest du in der Regel eine Bestimmte Component X in Version Y inklusive aller abhängigkeiten Materialisieren um damit zu arbeiten. Mit Buckminster machst du ein Query in die Component Cloud und dann wird deine Component inklusive aller Abhängikeiten in deinen Workspace gepackt, so das du direkt arbeiten kannst.
Im Unterschied zu Maven ist die Cloud aber nicht zwangsläufig durch ein Maven Repository dargestellt. Die Cloud kann aus 3 Maven Repositories, einem CVS Server, 3 Subversion Servern, einem Verzeichnis auf der Festplatte, einem FTP Server, einer Eclipse Update-Site,... bestehen. Weiterhin definiert jede Component Produkte die sich daraus herstellen lassen und Actions, zB ANT Scripte, daher kann Buckminster auch wunderbar als Build System fungieren.
Die Idee:
http://wiki.eclipse.org/Sharing_a_Project_(Buckminster)

Das Konzept:
http://wiki.eclipse.org/Why_Buckminster_?

Wenn du es mal in Aktion sehen willst (dann versteht man eigentlich erst wirklich was den Reiz der Sache ausmacht):
http://wiki.eclipse.org/Hello_XML_World_Example_(Buckminster)

Mit Maven lassen sich ähnlich coole Dinge anstellen, allerdings muss dafür in der Regel einiges an Vorarbeit geleistet werden.

Wären .project und .classpath sinnvoll, wenn 20 andere Personen mit unterschiedlichen Betriebssystemen gleichzeitig dran arbeiten?

Betriebssystem ist egal. .project und .classpath einzuchecken wäre nur dann ein Problem, wenn die 20 anderen Personen eine andere IDE verwenden die auch eine .project oder .classpath verwenden.

 

[TSH]

Danke für die ausführlichen Infos. Ich weiss, ich schweife jetzt ab, aber was steht denn genau in den .project und .classpath-Variablen bzw. wann verändern sich diese?

Ich weiss nicht, ob sich diese Buckminster Geschichte lohnt. Ich stand damals vor der Wahl Ant oder Maven und hab mich für Ant entschieden, weil mir Maven für dieses Projekt zu überdimensioniert erschien.

Wir benötigen 1 SVN, ein paar Targets und das war's. Mit dieser Import from SVN, Delete, Import from Ant sind wir gut klar gekommen, aber das ist ja vielleicht wirklich nicht der richtige Weg.

Außerdem würden wir das Ganze eh gerne als Dynamic Web Project anlegen. Was empfiehlst Du in diesem Fall? Da käme Buckminster vielleicht in Frage, oder?

Allerdings müsste der Nutzer ja schon irgendwie entscheiden, ob er den Trunk oder einen Branch ziehen möchte.

 

[Wildcard]

In Project steht der Name deines Projekts, die Natures (zB Java Nature) und die Builder.
Im .classpath steht der Classpath (in der Eclipse verständlichen Form), die source folders, pfade zu den Bibliotheken usw.

Ich weiss nicht, ob sich diese Buckminster Geschichte lohnt. Ich stand damals vor der Wahl Ant oder Maven und hab mich für Ant entschieden, weil mir Maven für dieses Projekt zu überdimensioniert erschien.

Die Geschichte ist sehr light weight. Es gibt kein Backend, keinen Server, keine Datenbanken.
Die legst irgendwohin eine Resource Map (eine XML Datei). In der Resource Map steht wo Components zu finden sind, also zB ein SVN Repository, oder ein Maven Repository, oder ein Verzeichnis auf der Platte.
Dann erstellst du ein einfaches Query. In dem Query steht eigentlich nur: Name der Komponente + Version und die Resource Map die verwendet werden soll. Dann schaut Buckminster in der Map nach einem Suchpfad für die Component (also zB das SVN Repository). Je nachdem was dort gefunden wird (Eclipse Projekt, OSGi Bundle, Maven Projekt, Jar, ...) berechnet Buckminster welche Dependencies deine wunsch Component hat und löst diese ebenfalls über die Resource Map auf. Es ist also eine reine Client Lösung die sich (optionaler) Server Komponenten bedienen kann.
Ich materialisiere und baue mit Buckminster zB eine Eclipse RCP Platform komplett ohne ANT Scripte. Alles was dazu nötig war ist ein Query, ca. 5 Zeilen XML und eine passende Resource Map, ca. 20 Zeilen XML.

 

[TSH]

Andererseits könnte ich doch einfach eine Konfiguration manuell oder zB via Yoxos zusammen stellen und allen Neu-Teilnehmern anbieten. Wo wäre bei Buckminster der Vorteil?

Das "Bauen" beschränkt sich auf Kompilieren und .war zusammenstellen. Ggf. gerne auch im Tomcat deployen oder gleich als Dynamic Web Project einbinden. Das sollte auch ohne Buckminster gehen.

Ich bin wirklich sehr daran interessiert, mehr über vernünftige Projektverwaltung zu lernen. Aber mir wird der Mehrwert noch nicht ganz klar. Bzw. ob sich die Einarbeitung da wirklich lohnt.

 

[maki]

Etwas vorgfertigtes, spezialisiertes, frei erhältliches & gut dokumentiertes ist allemal besser als es selbst zu machen, besonders wenn es darum geht dass mehrere Leute es nutzen sollen.

Maven2 lohnt sich, fast alle Apache Jakarta Projekte laufen drauf, Spring, etc. pp.
Konventionen für so gut wie alles, egal ob es sich um Webanwendungen (inkl. aller möglichen Frameworks wie JSF, struts, GWT, usw.), OSGi Bundles, EJBs oder gewöhnliche Jars handelt.
Klar gibt es eine Lernkurve.

denn mit Maven muss man den Maven weg gehen.

:toll:

Buckminster kenne ich persönlich nicht, aber hört sich besser an als alles selbst zu machen.

 

[Wildcard]

Andererseits könnte ich doch einfach eine Konfiguration manuell oder zB via Yoxos zusammen stellen und allen Neu-Teilnehmern anbieten. Wo wäre bei Buckminster der Vorteil?

Zwei unterschiedliche Dinge. Zwar kann Buckminster auch PlugIns in dein Development Eclipse installieren, aber das ist nicht der Fokus des Projekts. Bucksminter soll primär materialisieren und bauen.
Du bekommst einen neuen Kollegen ins Team und er soll anfangen zu arbeiten. Üblicherweise sieht das so aus:
-check Projekt x aus dem CVS aus
-check Projekt y aus dem SVN aus
-kopier die jar von Laufwerk z
-ruf den ANT Task, dann den ANT Task und zuletzt den ANT Task auf
-dann das nach dort kopieren
-hier noch was löschen

Buckminster:
File -> open a component query -> URL eingeben -> resolve und materialize

-Buckminster legt dir eine CVS Location in Eclipse an und checkt das Projekt x aus
-Buckminster erkennt das Projekt x Projekt y und die jar von Laufwerk z benötigt, legt die SVN Location von Projekt Y an und checkt es aus und kopiert dir die jar von Laufwerk z in den Workspace
-Buckminster erkennt das bevor Projekt x funktionieren kann noch drei Ant Tasks ausgeführt werden müssen, etwas kopiert und etwas gelöscht werden muss. Also wird das für dich erledigt.

Das Resultat ist ein fertig eingerichteter Workspace mit 2 Klicks.
Beim automatischen Builden hast du das gleiche Problem:
Das Buildsystem muss Abhängigkeiten auflösen, Build Files ausführen, Artefakte kopieren,...
Auch diesen Fall übernimmt Buckminster, denn die Abfolge der Schritte ist die gleiche.

Sinn und Zweck der Übung: Das was du zur Zeit manuell mit checkout, löschen, ANT-Tasks ausführen... frickelst, lässt sich bequem automatisieren und das hilft nicht nur dir, sondern auch deinen Kollegen.

 

[TSH]

Wieder mal: Vielen Dank für die ausführliche Erklärung, nur: So komplex ist unser Projekt gar nicht strukturiert. Es läuft eher so ab:

- Installiere Eclipse EE mit den Plugins SpringIDE und Subclipse oder Subversive.
- Check das Projekt aus dem SVN aus (trunk oder branch)
- Da Eclipse danach offensichtlich die Pfade nicht erkennt, lösche es und re-importiere es vom ausgecheckten Ant-File
- Führe 1 Ant-task aus
- Starte Tomcat

Für den letzten Punkt überlegen wir, auf ein Dynamic Web Project umzusteigern. Vielleicht könnte Buckminster ja da bei der Einrichtung hilfreich sein. Aber für den Build-Prozess erkenne ich noch nicht den Vorteil gegenüber den (existierenden und funktionierenden) Ant-Targets.

 

[Wildcard]

Zunächst mal ist Buckminster kein Builder für sich, es orchestriert Builder wie ANT, Maven, PDE,...
Und seit wann geht es hier darum euren bisherigen Build zu ersetzen?
Dein Problem war das Materialisieren eurer Projekte im Workspace und ich habe dir die mir bekannten Alternativen zu deinem eher unkonventionellen Vorgehen genannt.

 

[TSH]

Ist Materialisieren hierbei ein anderes Wort für Einrichten?

 

[Wildcard]

Materialisieren bedeutet in diesem Kontext 'wie bekommst du alles was du zum Arbeiten benötigst kompilierfähig in deinen Workspace'.