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:

Delphi-Quellcode:

CrazyLib.FluxCapacitor.pas

mit einem

Delphi-Quellcode:

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:

Zitat von Der schöne Günther (Beitrag 1286497)

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 :stupid:)

[Der schöne Günther]

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

[Jumpy]

Zitat:

Zitat von Der schöne Günther (Beitrag 1286497)

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? :wink:

[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)

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1286506)

Packages nur bei visuellen Komponenten in der K-Leiste. Alles andere ist Käse.

Sehe ich anders. Wir haben unsere Units in Packages gesteckt und kompilieren diese mit definierten Ausgabeverzeichnissen für die jeweiligen Plattformen. Der Bibliothekspfad ist entsprechend nur auf ein einziges Ausgabeverzeichnis (mit Platzhaltern für die Plattform) gesetzt. Die Suchpfade führen zu allen Quelltextunits.

Kompiliert wird das ganze per Batchdatei.

Auf diese Weise hat man die Quelltexte sauber von den kompilierten Units getrennt. Und die Units werden auch nicht dauernd unnötig neu kompiliert...

[Sir Rufo]

Der Vorteil von einem Package für eine Bibliothek ist die gesparte Zeit beim Kompilieren, da die Units ja schon kompiliert vorliegen.

Aufpassen muss man nur, dass man nicht den Debug-Code in die Anwendung bekommt. Darum erzeuge ich die DCU-Dateien immer im Verzeichnis "lib\DELPHI-VERSION\$(Platform)\$(Config)" und erzeuge die Dateien für alle Plattformen jeweils als Release und Debug.

Als Bibliotheks-Pfad dann "lib\DELPHI-VERSION\$(Platform)\Release" und bei Debug-DCU-Pfad "lib\DELPHI-VERSION\$(Platform)\Debug".

Die Suchpfade wie gehabt und der Drops ist gelutscht.

[jaenicke]

Ja, genau so. Und in Jenkins, das wir als Buildsystem nutzen, passiert das auch entsprechend automatisiert.

Der einzige echte Nachteil ist, dass man aufpassen muss, wenn man die Units gerade verändert. Denn dann sollen sie ja jedesmal kompiliert werden. Dafür kann man die betreffenden Units einfach temporär dem Projekt hinzufügen, am Ende das Sammelpackage neu erstellen und die Units wieder aus dem Projekt werfen (bzw. die Projektdateien aus dem Repository wiederherstellen).

[mquadrat]

Lässt sich das mit der Delphi-Version auch irgendwie automatisieren?

Im Szenario wäre es ja so, dass wir logischerweise nur die Variante für die Delphi Version, die wir verwenden (aktuell XE2) zur Verfügung stellen. Wir würden also das Projekt zur Verfügung stellen und jeder möge es sich dann selber compilieren. Oder anders formuliert: Ich hätte gern nur eine Projektdatei :-)

[NicoDE]

Zitat:

Zitat von jaenicke (Beitrag 1286554)

Der einzige echte Nachteil ist, dass man aufpassen muss, wenn man die Units gerade verändert. Denn dann sollen sie ja jedesmal kompiliert werden. Dafür kann man die betreffenden Units einfach temporär dem Projekt hinzufügen, am Ende das Sammelpackage neu erstellen und die Units wieder aus dem Projekt werfen (bzw. die Projektdateien aus dem Repository wiederherstellen).

Wäre es dann nicht einfacher das Package-Projekt in die Projektgruppe aufzunehmen und Abhängigkeiten zu definieren?

[jaenicke]

Zitat:

Zitat von mquadrat (Beitrag 1286556)

Ich hätte gern nur eine Projektdatei :-)

Solange die Projektdatei mit anderen Delphiversionen auch funktioniert, sprich die gleichen Units und Einstellungen nutzt, funktioniert das.
Allerdings ist das Ausgabeverzeichnis dann für alle gleich. Das wiederum ist schlecht für Parallelinstallationen. Ich weiß nicht, ob es auch dafür einen Platzhalter gibt, bei uns sind ohnehin eigene Packages pro Version notwendig.

Es sollte für potentielle Nutzer aber kein Problem sein das selbst anzupassen, sprich eigene Packages entsprechend zu erstellen.

Zitat:

Zitat von NicoDE (Beitrag 1286566)

Zitat:

Zitat von jaenicke (Beitrag 1286554)

Der einzige echte Nachteil ist, dass man aufpassen muss, wenn man die Units gerade verändert. Denn dann sollen sie ja jedesmal kompiliert werden. Dafür kann man die betreffenden Units einfach temporär dem Projekt hinzufügen, am Ende das Sammelpackage neu erstellen und die Units wieder aus dem Projekt werfen (bzw. die Projektdateien aus dem Repository wiederherstellen).

Wäre es dann nicht einfacher das Package-Projekt in die Projektgruppe aufzunehmen und Abhängigkeiten zu definieren?

Einzeln lässt sich das Komponentenprojekt auch schlecht kompilieren, da daran Buildskripte usw. hängen. Diese schieben die kompilierten Units hin- und her, so dass nicht nur die eine Unit kompiliert wird, sondern einiges mehr, so dass das Kompilieren nicht so schnell geht.