Schnellerer Sitzungsstart in Saros
In der heutigen Zeit spielt die Koordinierung von verteilten Entwicklern eine immer größere Rolle in der Softwareentwicklung. Saros ist ein Eclipse-Plugin, welches unter anderem dieses Szenario unterstützen soll. Die Entwickler können mithilfe von Saros auch über weite Entfernungen gemeinsam an einem Projekt arbeiten. Im Moment ist Saros nur für Eclipse verfügbar, es wird aber an einer Portierung auf IntelliJ gearbeitet.
1 Aktueller Stand
Wenn Entwickler zusammen an Quellcode arbeiten wollen, dann müssen sie dafür erst die benötigten Ressourcen austauschen. Bei größeren Projekten kann es dabei zu längeren Wartezeiten kommen, da diese Ressourcen erst archiviert, dann verschickt und dann auch wieder entpackt werden müssen. Während dieser Zeit müssen die Entwickler warten, bis sie anfangen können zu arbeiten. Um den Sitzungsaufbau zu beschleunigen, gibt es bereits eine Unterstützung für SVN-Projekte. Dabei benötigt der Saros-Client des Empfängers nur die URL und die Versionsnr. der Ressourcen und kann dann das Projekt über das Subclipse-Plugin herunterladen. Während einer laufenden Sitzung werden die Veränderungen an den geteilten Projekten mittels Activities übertragen.
2 Ziele
Das Ziel dieser Arbeit ist es, den Sitzungsstart im Saros Projekt für den Nutzer möglichst kurz zu gestalten. Dabei soll die Zeit, die zwischen dem Absenden der Einladung und dem Zeitpunkt, an dem der Nutzer anfangen kann zu arbeiten, verkürzt werden.
3 Ansätze
Eine Möglichkeit wäre es, den Sitzungsaufbau auf den Austausch von Metadaten zu beschränken und die benötigten Ressourcen im Hintergrund mittels Activities zu verschicken (siehe Abschnitt 3.2). Außerdem könnte man hier auch in Erwägung ziehen die Activities je nach Bedarf zu priorisieren, sodass eine ausgewählte Ressource in der Activity-Warteschlange bevorzugt wird (siehe Abschnitt 3.2).Eine weitere Verbesserungsmöglichkeit wäre es, neben dem direkten Laden der Ressourcen aus dem SVN noch ein weiteres Feature für Git-Systeme anzubieten.
3.1 Resourcen per Activities übertragen
Der erste Teil der Arbeit besteht darin, einige Vorbereitungen an dem bestehenden Code zu treffen, um dann später die Activities für die Übertragung größerer Projekte zu nutzen. Zum einen müsste darauf geachtet werden, dass der Java Heap nicht zu voll wird. Ausgehende Activities werden solange auf dem Heap gespeichert, bis sie verschickt werden. Wenn mehr Activities erzeugt als verschickt werden, kann es passieren, dass irgendwann kein freier Speicher mehr auf dem Heap zur Verfügung steht.
Ein weiterer Punkt ist das Blockieren der Benutzeroberfläche während neue Dateien angelegt werden. Hier könnte man das Erstellen im Hintergrund ausführen und die Events, die ausgelöst werden, sammeln und gemeinsam freigeben. Dadurch würde der Nutzer bei größeren Projekten nicht unterbrochen werden.
Die Übertragung mittels Activities würde außerdem dazu führen, dass der Wartungsaufwand der Software leicht reduziert werden könnte, da die Archivierung nun nicht mehr benötigt wird und ausgebaut werden kann.
3.2 Priorisierung der Activities
Im zweiten Teil der Arbeit wird dann die Priorisierung der Activities näher betrachtet. Mögliche Nutzungsszenarien würden folgendermaßen aussehen:- der Host wählt eine Ressource aus seinem Paket-Explorer aus
- der Eingeladene besitzt eine Liste von Platzhaltern, unter denen er die zu bevorzugende Ressource auswählen kann
4 Evaluierung der Ergebnisse
Zur Überprüfung der Ergebnisse dieser Arbeit wird regelmäßig die Zeit, die für den Sitzungsaufbau benötigt wird, gemessen. Hierbei werden unterschiedlich Nutzungsszenarien betrachtet.