SIMON 0.3 stable kurz vor dem Release

Byte-Welt - Projekte / Projects Allgemeines zu Projekten / Generals
1

Hallo zusammen,

ich weiß, ich hab hier schon einen SIMON Thread. Aber der hat mittlerweile so viele Seiten, das sich den wohl keiner mehr durchlesen will.

Was ich eigentlich sagen wollte:

Meine SIMON-Library steht kurz vor dem dritten stable release.

Mittlerweile sind einige Features dazu bekommen (“der kleine SIMON wächst und wird größer :-)”).

Unter anderem:

  • Proxy Support: Der Client kann nun durch einen Proxy hindurch sich mit dem Server verbinden
  • **SSL **Support: SSL verschlüsselung zwischen Client und Server (auch durch den Proxy hindurch) ist ebenfalls möglich
  • RawChannels für schnellen Datentransfer ohne zeitraubende reflection&serialisierung
  • Austauschbares Protokoll
  • Connection Loss Detection: Binnen weniger Sekunden erkennen ob ein Client oder Server “weg” ist
  • PublishService: SIMON Server im lokalen Netzwerk automatisiert auffinden (verwendet Broadcasts, geht also nur im passenden LAN).

Und die restlichen Grundfeatures:

  • Verwendung von Java NIO für beste **Performance **und Skalierbarkeit
  • Verwendung von Thread-Pools statt ein Thread pro Client
  • Remote Procedure Calls: Client kann Methoden am Server und Server Methoden am Client aufrufen
  • Router- und Firewallfreundliche einrichtung
  • …

Wer wer wissen möchte:
http://dev.root1.de/projects/simon

Bei Fragen und Problemen: Bitte den Bugtracker und/oder das Projektforum benutzen. Oder einfach hier fragen…

Gruß
Alex

2

Klingt richtig gut! Hast bestimmt wieder 'ne feine Arbeit gemacht. :wink:

3

Ich ich hoffe es doch :slight_smile:

Freu mich über jedes Feedback.

Gruß
Alex

4

Nach dem Wechsel von java-forum.org hierher, möchte ich den Thread nochmal ausgraben (damit crawlende Suchmaschinen auch wieder up2date sind) und auf die aktuelle Version 1.1.3, sowie das kurz vor dem Release stehende 1.2.0 hinweisen. Seit Version 0.3 hat sich ja verdammt viel getan…

Link zur Projektseite mit Wiki, Support-Forum und Beispielen: http://dev.root1.de/projects/simon

Gruß
Alex

5

[QUOTE=tuxedo]…
(damit crawlende Suchmaschinen auch wieder up2date sind)[/QUOTE]
Dann füttere sie hier auch mit ein paar kurzen Stichworten :wink:

6

Hallo Tuxedo,

gefällt mir sehr gut, wie du deine Software präsentierst, so mit Redmine, Wiki, Nexus, Jenkins, Maven Site, API Docs, etc. Alles wie es sein sollte :wink:

Aber mal eine Frage: Du nutzt SVN statt Git. Das hat mich etwas verwundert, da ich der Überzeugung bin, wer sich einmal mit Git auseinandergesetzt hat, wird es nicht mehr missen wollen.

Das interessiert mich einfach nur. Ich möchte keinen Glaubenskrieg damit auslösen.

7

[QUOTE=deetee]Hallo Tuxedo,

gefällt mir sehr gut, wie du deine Software präsentierst, so mit Redmine, Wiki, Nexus, Jenkins, Maven Site, API Docs, etc. Alles wie es sein sollte :wink:
[/quote]

Danke für die Blumen …

Aber mal eine Frage: Du nutzt SVN statt Git. Das hat mich etwas verwundert, da ich der Überzeugung bin, wer sich einmal mit Git auseinandergesetzt hat, wird es nicht mehr missen wollen.

Hab Git natürlich auch schon ausprobiert. Ist eine feine Sache. Aber ich sehe noch keinen Sinn für SIMON darin: SIMON wird aktuell nur von einer Person - meine Wenigkeit - entwickelt. Alleine brauch ich kein verteiltes System zur Versionsverwaltung. Ein Vorteil von Git wäre das relativ einfache einbringen von Patchs/Erweiterungen durch Dritte. Aber auch das ist (noch) nicht der Fall: Die Anzahl an Patchs/Erweiterungen die ich seit Gründung des Projekts bekommen habe kannst du an einer Hand abzählen. Und unter’m Strich kennen sich - so meine Vermutung - noch mehr Leute mit SVN als mit Git aus.

Nur auf Git zu wechseln weil Git gerade „in Mode“ ist möchte ich nicht. Dafür ist mir meine Zeit zu schade. Die Zeit stecke ich lieber in die Entwicklung von SIMON. Wenn es sich abzeichnet dass SIMON von Git deutlich profitieren würde, dann würde ich auch wechseln. Aber aktuell ist der Bedarf einfach noch nicht vorhanden.

Frage geklärt?

Gruß
Alex

8

Ok, ist einerseits verständlich. Aber

du würdest ja von Git ebenfalls profitieren, weil du dich dann damit beschäftigst und arbeitest. Ist ja auch was wert, oder?

Und du könntest deine Software auf Github präsentieren, die für Open Source wohl die beste Plattform ist um bekannter zu werden.

9

du würdest ja von Git ebenfalls profitieren, weil du dich dann damit beschäftigst und arbeitest. Ist ja auch was wert, oder?

Prinzipiell ja. Aber ich will ja nicht einfach alles aus SVN auschecken und in Git einchecken. Ich will die Historie mitnehmen. Und alles was da dran hängt muss ich auch umstellen. Vorteile bringt mir Git in dem Projekt nix. In anderen Projekten hab ich’s schon benutzt und Erfahrungen gesammelt.

Und du könntest deine Software auf Github präsentieren, die für Open Source wohl die beste Plattform ist um bekannter zu werden.

Anfangs war ich bei java.net und hab dort alles gehostet. Bin aber davon abgekommen. Bin gern selbst Herr über das System. Wenn was nicht geht weiß ich wenigstens wieso und warum und kann was dagegen tun.

Wer nach RMI und Java googelt, stößt relativ schnell auf SIMON. Ein Beispiel: „java rmi alternative“ → java rmi - Google Suche

Erstes Suchergebnis: Die Wikipedia-Seite von SIMON.

Github ist für mich (noch) nicht die Einstiegsseite um nach neuen/besseren Libs zu suchen.

10

Hab SIMON noch nicht benutzt und auch den Code nicht gesehen, aber für die Art und Weise wie du dein Projekt präsentierst bekommst du auch von mir alle verfügbaren Daumen nach oben! Sieht echt super aus. :slight_smile:

Und damit dieser Post nicht nur reine Huldigung ist gleich eine Frage hinterher. Verzeih mir, wenn ich zu blind war um es selbst zu finden. Hab mal kurz den Einstieg in SIMON überflogen und finde auch das Tutorial recht nett anzuschauen, aber gibts so nen Sample Code auch direkt zum Download? Sodass man tatsächlich einfach nur aus SVN/Git irgendwoher mal sowas auscheckt und laufen lässt? Oder muss man diese einfachen Beispiele dann doch selbst machen? Ich frage deshalb, weil ich da ein bisschen verwöhnt bin und bei verschiedenen Themen (Eclipse GEF, Tycho, …) immer irgendwelche Examples hatte mit denen ich spielen konnte. :slight_smile:

11

Klaro gibt’s fertigen Beispielcode zum runterladen und laufen lassen:

http://svn.root1.de/svn/simon/trunk/samples/
http://svn.root1.de/svn/simon/trunk/samples/src/main/java/de/root1/simon/samples/

Gruß
Alex

12

Super, danke!
Falls es nicht schon in deinem Wiki steht (hatte es auf Anhieb nicht gefunden), dann wäre es sicherlich einen Eintrag wert. :slight_smile:

13

Ui ui ui, in Git gibt es eine SVN Bridge, die es einen ermöglicht, die komplette SVN-Historie in ein Git-Repository zu klonen. Und ich behaupte einfach mal, trotz Existenz dieser, mag kein Open Source Commiter mit SVN arbeiten. Vielleicht der Grund warum so wenig Patches kommen :stuck_out_tongue: Auch wenn ein eigenes Git Repository (am eigenen Server) noch bisschen mehr Aufwand zum commiten ist, als bei Github, Pull Requests per Email sind auch halbwegs komfortabel.

14

Leider sind bei der ASF immer noch viele Projekte auf SVN :frowning: und von git nach SVN committen ist immer eine Geduldsprobe.

15

Genau das was ich sagte. Trotz git-svn tut sich das keiner an ^^ Trotz Open Source ist SVN nicht dafür gedacht, Forks zu unterstützen.

16

Zum Thema Patch:

Ein SVN Checkout ist genauso easy wie mit Git. Also hier kein Plus-Punkt für Git. Evtl. sogar ein Plus-Punkt für SVN, da SVN in IDEs eine doch breitere Unterstützung (da meist schon mitgeliefert) findet. Aber darüber kann man sich streiten, und das wird sich in Zukunft sicherlich auch ändern.

Dann hat man den Source erstmal auf der Platte. Beim Ändern des Sources kann einem Git auch nicht helfen. Das muss man selbst tun. Eine Patch-File generiert man in der IDE meist mit 1-2 Klicks. Dann sollte man sich ja irgendwie bei der Projektleitung melden und mitteilen was man da fabriziert hat. Und in diesem Zug kann man das Patch-File anhängen. Alles kein wirklicher Aufwand. Mit Git hätte man lediglich das anhängen des Patches an die Mitteilung gespart, aber statt dem Patch-Generieren einen Pull-Request angestoßen.

Wem diese 1-2 Klicks für das anhängen des Patch-Files absolut zu viel und unzumutbar erscheinen: Ganz ehrlich: So einer erstellt dann auch keinen Feature-Patch der ihn in der Entwicklung vllt. 1-2h gekostet hat. Denn das ist dann sicher auch zu viel.

Git und SVN zu synchronisieren fang ich nicht an. Entweder das eine, oder das andere. Und aktuell bleib ich erstmal bei SVN, da SIMON durch Git keinen wirklich nennenswerten Vorteil erfährt.

Und ich behaupte einfach mal, trotz Existenz dieser, mag kein Open Source Commiter mit SVN arbeiten. Vielleicht der Grund warum so wenig Patches kommen

Aha, und bevor es Git gab waren also alle OpenSource Commiter täglich am kotzen und haben sich beim commiten täglich einen Arm gebrochen und ein Bein ausgerissen, eben weil SVN so übel zu bedienen ist?! Naja, ist vielleich doch ein wenig übertrieben, oder meinst du nicht? SVN ist an und für sich ein gutes CVS. Nur ist es eben nicht für weit verstreute Teams und Gruppen gedacht, die alle quer Beet am Code arbeiten. Gut, dafür gibt’s ja jetzt Git.
Bis dato gabs nur ein oder zwei Leute die sich überhaupt mal (noch bevor sie an einen Patch gedacht haben) sichtbar (also im Support-Forum) mit dem Code beschäftigt haben. Der überwiegende Anteil derer die sich irgendwie zu Wort melden haben ganz andere Probleme. Anhand deren Schilderungen sieht man, dass sie von Materie (Wie funktioniert RPC intern?) eigentlich keinen schimmer haben (was übrigens zeigt dass es gut ist dass es so einfache Frameworks wie RMI und SIMON gibt). Von daher ist noch nicht ersichtlich dass es notwendig wird, ein verteiltes CVS einzuführen.

Trotz Open Source ist SVN nicht dafür gedacht, Forks zu unterstützen.

SIMON soll ja auch nicht unbedingt geforkt werden. Forks teilen die Entwicklungskraft nur auf weitere Teams auf, statt die gesamte Energie zusammen in einem Projekt zu bündeln. Aber gut, da gibt’s ja auch ganze Glaubens- und Meinungskriege dazu.

@Gonzo
Ich ergänze das Wiki entsprechend. Danke für den Hinweis.

17

Jein, bei Github Projekten machst du immer einen Fork in deinen eigenen Account um Commit-Rechte zu haben. Bist du fertig mit deinem Patch oder deinem Feature stellst du einen Pull-Request an das original Repo und einer mit Commit-Rechten kann ihn dann einfach übernehmen und einpflegen,

18

Mir scheint Git verwendet die Begriffe etwas anders. Dieser “Mini-Fork” würde CVS-Übergreifend dann wohl als Branch bezeichnet werden. Denn die Intention ist es nicht einen echten Fork zu erstellen, sondern zu branchen (git: fork) und später wieder zu mergen (git: pull request).

19

Nein du clonest das komplette Repo, ergo ist ein voller Fork :slight_smile: Nur forken heißt nicht zwangsweise, dass man nur noch für sich werkelt und nicht mehr ans Main-Repo zurück committed.

20

Ich meinte ja auch nicht Git und SVN synchronisieren. Sondern einmalig mit git-svn ein Repo zu erzeugen das die komplette SVN-Historie erhält und dann mit Git weiterarbeiten :wink:

Klar kann ich ein SVN einfach auschecken, aber ich kann keine lokalen Commits machen, was ein Hauptbestandteil von Git ist.