Open Sourcing von Komponenten - Best Practices?

[mquadrat]

Hallo zusammen,

wir werden nach und nach unsere intern verwendeten Bibliotheken und Komponenten als Open Source zur Verfügung stellen. Aktuell ist das ganze eine ziemlich lose Sammlung von Klassen, die teilweise noch nicht mal in Packages stecken. Wir haben also eine grüne Wiese mit viel "Wünsch-dir-was".

Mich würde daher mal interessieren, was es für "Vorlieben" in der Community gibt. Betrifft die gesamte Bandbreite, also beginnend mit der Frage, ob die Klassennamen ein Prefix haben sollen, ob es je Klasse eine Datei oder eine Sammlung sein soll (Wartbarkeit vs. weniger uses-Einträge), wie die Packages aufgebaut sein sollten etc. Schwierig wird es beim Thema Deployment, da es IMHO für den zukünftigen Package-Manager noch keine öffentlichen Details gibt. Aber ich denke mal GitHub-Unterstützung wird schon drin sein.

Hier sind ja doch einige, die in diversen Open-Source Projekten vertreten sind, da wird es sicher einige "lesson learned" bzw. "wie man es nicht machen sollte" geben.

Bin auf den Erfahrungsaustausch gespannt.

[sh17]

Nicht zu viele Abhängigkeiten zwischen den Units. Aus diesem Grund mache ich bei JCL und JVCL einen großen Bogen drum. Wenn eine Komponente separat existieren kann, dann sollte das auch so bleiben.

[Nersgatt]

Package oder nicht, hat Vor- und Nachteile.

Wenn Du Units hast, die eigenständig funktionieren, dann finde ich es besser, diese Unit einfach einzeln rauszugeben. Die füge ich dann meinem Projekt hinzu und fertig.
Wenn Du aber Abhängigkeiten zwischen mehreren (vielen) Units hast, dann finde ich es besser, die zu einem Package zusammen zu fassen.

[Der schöne Günther]

Klassen würde ich keine Pre- und Postfixe andichten wollen. Eigentlich wäre dazu der Namensraum da. Da Delphi als billigen Ersatz immerhin Punkte in Unitnamen zulässt könnte man ja immerhin die Benennung der Units reglementieren: CrazyLib.FluxCapacitor.pas mit einem TFluxCapacitor drinnen.

Ein schönes Beispiel dafür finde ich die (leider recht unbekannte) Lib von Cromis.net:
https://www.cromis.net/svn/cromis/lib/pas/CromisCode

[Insider2004]

Packages nur bei visuellen Komponenten in der K-Leiste. Alles andere ist Käse. Da gibt's Leute die machen aus jeder Prozedur eine Komponente.

[himitsu]

Zitat von Der schöne Günther:

Klassen würde ich keine Pre- und Postfixe andichten wollen.

Es kommt drauf an.

Ein supergutes Edit sollte man aber nicht TEdit nennen, denn in der VCL IDE gibt es keine Namensräume.
(OK, gibt es, aber nicht im FormDesigner ... Beispiel )

[Der schöne Günther]

Klar, an grafische Komponenten habe ich jetzt überhaupt nicht gedacht...

[Jumpy]

Zitat von Der schöne Günther:

Ein schönes Beispiel dafür finde ich die (leider recht unbekannte) Lib von Cromis.net:
https://www.cromis.net/svn/cromis/lib/pas/CromisCode

Haste mal deine Zugangsdaten parat, damit man sich das anschauen kann?

[Der schöne Günther]

Ist Subversion und öffentlich (also eigentlich svn://). Mit dem Browser sehe ich da auch nur ein "Zugriff verweigert".

[himitsu]

Der Browser lehnt blos das "ungültige" SSL-Zertifikat ab. (beim https)
Du mußt also nur eine Ausnahme für's SSL dieser Webseite im Browser aufnehmen.

Zitat:

www.cromis.net verwendet ein ungültiges Sicherheitszertifikat. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde. Das Zertifikat gilt nur für Cromis.DAKSKOBLER-LOCAL.

Und via svn://cromis.net/irgendwas gings auch nicht (tortoise ... der Browser selber kennt ja kein SVN-Protokoll)