Eigene Java-Library promoten (Lib zur Barcode-Generierung)

[inflamer]

Hallo Forum,

ich habe eine Java-Bibliothek geschrieben, welche ein- und zweidimensionale Barcodes generiert, um sie etwa anschließend zu drucken oder als Raster- oder Vektorgrafik zu speichern.

Das Ergebnis seht ihr hier:

Barcode-Lib4J – Open-Source Barcode Library for Java

Open-Source Java library for creating, printing and storing 1D and 2D barcodes as vector (PDF, EPS, SVG) and raster (PNG, BMP, JPG) images.

www.vw-software.com

Dabei habe ich mich bemüht, das Download-Package gemäß "gängiger Konventionen" zu gestalten (z.B. ist selbstverständlich ein JavaDoc sowie eine "pom.xml" dabei), damit die Library ohne viel Fummelei direkt benutzt werden kann.

Es wäre super, wenn die Fories mal einen Blick in das innere der ZIP-Datei werfen und anschließend ein kurzes Feedback geben könnten, ob im Package evtl. etwas fehlt oder nicht optimal ist.

Zum anderen bin ich etwas enttäuscht über die recht geringe Anzahl von Besuchern über Google und Co., obwohl die o.g. URL dort eigentlich ganz gut rankt. Könnte es daran liegen, dass man als Entwickler normalerweise nicht bei Google nach Bibliotheken sucht, sondern direkt auf Github, Maven und Konsorten?

Ich würde die Seite gerne etwas promoten, habt ihr eine Idee wo/wie? Es sollte vielleicht nicht unbedingt GitHub sein, da das eigentliche Ziel darin besteht, Backlinks zur Library-Seite zu erhalten und damit auf indirektem Wege das Ranking der gesamten Website bei Suchmaschinen zu erhöhen. Die Library soll dabei als kostenloses Give-Away dienen.

Danke!

 

[thecain]

Könnte es daran liegen, dass man als Entwickler normalerweise nicht bei Google nach Bibliotheken sucht, sondern direkt auf Github, Maven und Konsorten?

Ziemlich sicher. Bzw. Ich würde nie eine Library einsetzen, die ich einfach so als jar runterladen muss. Maven ist Pflicht. Zudem fehlen mir auf den ersten Blick Infos zur Lizenz.

 

[KonradN]

Erst einmal super, dass Du da sowas als Open Source Projekt aufgesetzt hast. Statt es aber nur als ZIP bereit zu stellen:

- Sourcen gehören in eine Sourcecode Verwaltung. Hier bieten sich also direkt GitHub, GitLab, ... an. Aber natürlich wäre auch eine selbst gehostete Lösung wie Gitea oder so ok. Aber ich möchte halt nicht erst ein ZIP herunter laden um es dann zu entpacken und so. Statt dessen würde ich da halt gerne direkt im Browser schauen ... Auch Änderungen möchte ich so nachvollziehen können ...

- Library - Hier wäre es super, wenn das Paket auch im Maven Repository zu finden wäre. Dann sind auch weitere Abhängigkeiten kein Thema mehr...

- Verwaltung von Abhängigkeiten - Es ist super, dass Du auch PDF oder so generieren kannst, aber braucht man das (fast) immer? Hier kann man ggf. aufteilen. Dann hast Du mehrere Projekte. Also sowas wie barcode-core, barcode-pdf, barcode-swing, barcode-fx, ... (so aus den Fingern gesaugt) ... barcode-pdf braucht eine pdf Abhängigkeit, swing braucht das desktop Modul vom JDK, FX braucht das JavaFX als Abhängigkeit ...
Wenn ich aber nur Bilder erzeugen will um die dann auf einer Webseite anzuzeigen oder so: Da brauche ich dann kein desktop Modul, kein JavaFX, keine PDF Library ....

Ansonsten habe ich es mir noch nicht wirklich im Detail angesehen .. das werde ich aber noch in den nächten Tagen versuchen. Also bitte entschuldigem wenn ich auf dem erstenBlick etwas übersehen habe.

 

[inflamer]

Ziemlich sicher. Bzw. Ich würde nie eine Library einsetzen, die ich einfach so als jar runterladen muss. Maven ist Pflicht. Zudem fehlen mir auf den ersten Blick Infos zur Lizenz.

Ok, das bestätigt schon mal meinen "Verdacht". Lizenzmodell (Apache 2.0) ist allerdings auf der Website (rechts oben) angegeben. Und die JAR-Datei ist halt nur optional, falls man den Source Code nicht selbst aus der ZIP-Datei kompilieren will.

EDIT: Ich meine aber mal von einigen recht populären Bibliotheken gelesen zu haben, die auf keinem der gängigen Repositories zu finden sind, sondern nur auf der Hersteller-Website. Damit funzt es dann ja anscheinend sehr wohl...

Erst einmal super, dass Du da sowas als Open Source Projekt aufgesetzt hast. Statt es aber nur als ZIP bereit zu stellen:

- Sourcen gehören in eine Sourcecode Verwaltung. Hier bieten sich also direkt GitHub, GitLab, ... an. Aber natürlich wäre auch eine selbst gehostete Lösung wie Gitea oder so ok. Aber ich möchte halt nicht erst ein ZIP herunter laden um es dann zu entpacken und so. Statt dessen würde ich da halt gerne direkt im Browser schauen ... Auch Änderungen möchte ich so nachvollziehen können ...

- Library - Hier wäre es super, wenn das Paket auch im Maven Repository zu finden wäre. Dann sind auch weitere Abhängigkeiten kein Thema mehr...

- Verwaltung von Abhängigkeiten - Es ist super, dass Du auch PDF oder so generieren kannst, aber braucht man das (fast) immer? Hier kann man ggf. aufteilen. Dann hast Du mehrere Projekte. Also sowas wie barcode-core, barcode-pdf, barcode-swing, barcode-fx, ... (so aus den Fingern gesaugt) ... barcode-pdf braucht eine pdf Abhängigkeit, swing braucht das desktop Modul vom JDK, FX braucht das JavaFX als Abhängigkeit ...
Wenn ich aber nur Bilder erzeugen will um die dann auf einer Webseite anzuzeigen oder so: Da brauche ich dann kein desktop Modul, kein JavaFX, keine PDF Library ....

Ansonsten habe ich es mir noch nicht wirklich im Detail angesehen .. das werde ich aber noch in den nächten Tagen versuchen. Also bitte entschuldigem wenn ich auf dem erstenBlick etwas übersehen habe.

Hallo Konrad.

Ja, GitHub, GitLab, Maven und Co. - aus Sicht des Entwicklers absolut praktische Dinge. In meinem Fall verfehlt das aber leider das von mir angestrebte Ziel, nämlich die Promotion der Website. Stelle ich die Library auf einem der genannten Reposirories zur Verfügung, würden sich die Leute das Teil direkt von dort holen, allerdings "an meiner Website vorbei". Für Entwickler bequem und legitim, für mich leider nicht ganz so optimal.

Bzgl. Aufteilung: Stimme dir zu: das könnte ich mir tatsächlich nochmal angucken. Auch wenn wir hier tatsächlich bloß von einer einzigen Abhängigkeit reden (OpenPDF).

 

[thecain]

Lizenzmodell (Apache 2.0) ist allerdings auf der Website (rechts oben) angegeben.

Jetzt am PC tatsächlich, auf dem Mobile sah es so aus, als beziehe sich das auf OpenPDF.



Eine Möglichkeit für deine Website wäre evtl:

• Veröffentlichen auf Github + maven
• Dokumentation und Beispiele auf deiner Webseite

 

[KonradN]

In meinem Fall verfehlt das aber leider das von mir angestrebte Ziel, nämlich die Promotion der Website.

Hier wäre ich vorsichtig. Den Source woanders abzulegen bedeutet ja nicht, dass Du dort dann die Webseite hinterlegen wirst. In der README.md kann einfach nur der Hinweis auf die Webseite sein. Alle wichtigen Inhalte können dort sein.

Und wenn Entwickler die Library gut finden, dann ist das Risiko schlicht hoch, dass sie dies übernehmen. Es ist ja unter einer Open Source Lizenz. Also kann man Deinen Source nehmen und auf Github stellen. Und das kann man dann weiter ausbauen ... Das nur als kleiner Hinweis: klar, Du hast gewisse Interessen. Aber wenn Du Entwicklern nicht entgegen kommst, dann werden diese entweder andere Abhängigkeiten nutzen oder eben das, was fehlt, selbst bereit stellen.

Und das ist nicht einmal böse gemeint. Es ist nicht im Maven Repository? Für meine CI/CD Pipeline brauche ich es dort aber. Also was ist da mein einfachster Weg? Da kann es am Einfachsten sein, da einen Clone zu erstellen nur um es dann im Repository hoch zu laden. (Sowas in der Art mache ich jedoch nicht mit dem Maven Repository sondern ich baue ein lokales Repository, welches ich dann mit im Projekt einchecke ...)

 

[inflamer]

@thecain. Ist vlt. eine erwägenswerte Option. Danke!

@Konrad. Da denk ich natürlich dran - ist OpenSource, also k.p.

Absichern gegen sowas kann man sich (zumindest teilweise), indem man beispielsweise im Zuge des Build-Prozesses etwaige JavaDocs aus dem SourceCode entfernt.

Ok. Ich denke weiter drüber nach...

 

[KonradN]

Absichern gegen sowas kann man sich (zumindest teilweise), indem man beispielsweise im Zuge des Build-Prozesses etwaige JavaDocs aus dem SourceCode entfernt.

Die sinnvolle Absicherung ist, es den Entwicklern so zu geben, dass sie damit so problemlos arbeiten können, dass sie dies nutzen wollen. Dass zusätzliche Aufwände einfach unnötig sind.

Generell sollte man Red Flags vermeiden. Wenn ich nicht direkt in den Source schauen kann und direkt die Change History sehen kann (Was wurde in dem letzten Update angepasst? Wie dringend ist es, dass ich da jetzt aktualisiere?), wenn der Source Code nicht direkt so verfügbar ist, dass ich ihn prüfen lassen kann (Es gibt genug Code Review Tools wie snyk, die das Projekt untersuchen und mir einen Report geben) und all sowas, dann nutze ich es nicht oder wenn ich es doch nutzen können will: Dann muss ich aktiv werden.

JavaDoc Kommentare zu entfernen sorgt dann nur dazu, dass der Code wieder eine grosse rote Fahne zeigt ... und vermutlich wird es nichts bringen, denn ich öffne das Projekt vermutlich einfach nur in eine IDE mit guter AI Unterstützung: Schreibe JavaDoc bei allen Klasse und allem Membern der Klassen. Und schon habe ich einen Code, der von der Qualität her vermutlich nicht schlecht kommentiert ist. Das ist zumindest meine Erfahrung ...

Das nur noch einmal, um meine Sichtweise klar zu stellen. Generell ist es Dein Projekt und Du kannst da machen, was Du willst und ich will Dir da nicht rein reden. Es sind alles nur Vorschläge, die eben aus meiner sehr individuellen Sichtweise kommen.