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.

 

[White_Fox]

Mal so allgemein: Wenn du das quelloffen in die Welt setzt, dann ist es völlig normal daß andere das an ihre Bedürfnisse anpassen. Eben z.B. alles für PDF- und Bilderzeugung rauswerfen, wenn man den Barcode nur auf dem Bildschirm anzeigen will, sein Programm aber nicht mit unnötigem Ballast aufpumpen will.

Und es will sich auch niemand irgendwelchen möglicherweise sogar gefährlichen Scheiß in seine Software holen, indem er irgendeine fremde Jar einbaut. Auch wenn du das natürlich nicht vorhast – aber man kennt diejenigen hinter irgendeiner Webseite in der Regel ja nicht. Und es ist ja nicht so, daß es Schadsoftwareverbreitung per Bibliothek nicht gäbe:

https://www.java-forum.org/thema/sicherheitshinweis-xz-lzma-sshd-backdoor.204194/

Maven/Gradle-Repositories sind ja schon angesprochen worden. Zumindest in Gradle kann man alles mögliche als Quelle vor die Füße schmeißen, auch eine URL zu irgendeinem online zugänglichen git-Repository. Eine kurze Anleitung was man dazu in seine Builddatei schreiben muß, idealerweise mit einem Button daneben der den Kram direkt in die Zwischenablage kopiert, senkt die Hemmschwelle ganz erheblich.
Lokale Abhängigkeiten sind zumindest in Gradle etwas...problematisch.

Ob das jetzt unbedingt GitHub sein muß...wäre mir persönlich eher egal. GitHub und GitLab bieten allerlei interessante Trackingwerkzeuge, auch wer z.B. alles dein Repo geforkt hat. Ich kann es aber auch nachvollziehen, wenn man nicht auf GitHub anbieten will. (Meine Projekte z.B. liegen nicht umsonst auf Sourceforge.)

Wenn es dir aber darum geht, deine Webseite bekannter zu machen: Soweit ich weiß unterstützen GutHub und GitLab (und ich meine, auch Sourceforge) eigene Webseiten. Vielleicht kannst du deine Seite da ja irgendwie reinverlinken?
Ich kenne auch Projekte die zwar eine eigene Webseite haben und man die Software auch davon herunterladen kann, ihr Entwicklerrepository aber dennoch auf GitHub haben und von ihrer Seite dorthin verlinken. Vielleicht wäre sowas in der Art etwas für dich...?

PS:
Ich finde deine Seite mit der Doku dazu allerdings recht gut gemacht.

 

[mihe7]

Ich finde das auch wirklich sehr schön gemacht. Allerdings glaube ich, dass Du über github und Maven Central Dich/Deine Website/Firma wesentlich stärker in den Fokus rücken kannst als über den "Vertrieb" über die eigene Website.

Warum?

1. Wenn ich eine Lib suche und verwenden möchte, dann nehme ich den Weg des geringsten Widerstands. Heißt: ich schmeiße Google an, schau was mir auf Github/Maven Central geboten wird. Dann: welche Lizenz? Dann: Doku überfliegen und da wäre ich dann ggf. schon auf Deiner Seite.
2. Je besser das Ding ist und je einfacher es zu verwenden ist, desto stärker verbreitet sich das auch.
3. Wenn Du es nicht machst, macht es jemand anders.

 

[LimDul]

(...)
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.

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

Kurz und knapp: Ein Jar, die ich runterladen muss ist extrem viel Fummelei um sie zu nutzen.

In der Firma würden wir eine solche Lib nie im Leben einsetzen. Etwas was nicht auf maven central ist, existiert nicht oder ist etwas, was kommerziell ist und es gute Gründe gibt es (inkl. Support) zu lizenzieren. Eine Random Barcode Lib fällt da nicht drunter.

Auch Privat - wenn ich privat entwickle, will ich einfach die Dependency in der pom.xml eintragen und dann soll das funktionieren. Das ich mir die Mühe mache ein Jar Datei irgendwo runterzuladen, sie irgendwie in mein maven projekt reinzufummeln? Warum soll ich das tun. Da müsste die Lib schon wahnsinnige Plus-Punkte gegenüber anderen Libs haben. Und das sehe ich bei einer Barcode Lib nicht. Ich wäre auf der Seite sofort wieder weg, sobald ich sehe, dass das zwar Open Source ist, es aber keinen Zugriff auf das GIT Repo gibt und insbesondere nicht auf maven central verfügbar ist.

Eine Bibliothek muss in erster Linie geräuschlos funktionieren. Sie zu nutzen um Besucher auf eine Webseite zu zwingen - das wird schlicht nicht funktionieren.

 

[mjustin]

Zum Promoten eigener Java-Bibliotheken verwende ich unter anderem die Forum-Seiten auf https://coderanch.com/forums - und dort konkret das Unter-Forum "blatant advertising". Posts, die man dort einstellt, werden auch auf den anderen Forum-Seiten der Coderanch angezeigt. Es kostet nichts, optional kann man auch bezahlte Links schalten, die z.B. unter andere Posts gesetzt werden.

Eine andere Möglichkeit wäre das Anlegen eines Blogs, in dem Neuigkeiten (Releases, neue Features, Beispielcode) zu finden sind.

Was auch für Besuche auf der eigenen Seite sorgen würde: eine interaktive Erzeugung eines Barcode auf der Webseite. Dazu braucht man nur entweder eine eigene serverseitige Java-Umgebung (Apache Tomcat) oder eine Java-Funktion auf Google Cloud Run oder Azure. Mit etwas HTML (iframe oder img-Element, HTML Formular) kann dann die Barcode Lib per HTTP GET auf der eigenen Webseite aufgerufen werden. Google Cloud Run macht das Ausführen von Java-Code sehr leicht, es ist dem Erstellen eines Servlets sehr ähnlich.

 

[inflamer]

Vielen Dank für die vielen wertvollen Tipps! Die Antwort meinerseits ließ nun etwas auf sich warten, dafür hat sich allerdings einiges getan seit meiner letzten Rückmeldung:

1. Neue Version ist erschienen (2.0.1 -> 2.0.2), wo dank Anwendung von Reflection beim Kompilieren des Quellcodes die "OpenPDF"-Bibliothek nicht länger benötigt wird. Des Weiteren werden JavaDocs nicht mehr aus dem Quellcode entfernt (Tipp von @KonradN).

2. Verfügbarkeit auf GitHub (Findet ihr hier etwas, was noch verbessert werden sollte, z.B. an der README.md ?)

3. Verfügbarkeit auf Maven Central (Frage: Sollte ich die <description> in der "pom.xml" evtl. um eine Aufzählung weiterer gängiger Barcode-Typen erweitern (z.B. "Also supported: Code 128, Interleaved 2 of 5, ..."), falls ein Interessent nach konkreten Barcode-Typen sucht? Oder wäre eine solche <description> dann etwas zu lang?)


Da sicher viele hier regelmäßig auf den genannten Plattformen "unterwegs" sind, fällt euch ja möglicherweise noch etwas auf, was noch verbessert werden könnte. Hauptziel ist (zur Erinnerung) die Promotion meiner Website.

Mit dem Gedanken von einer interaktiven Erzeugung von Barcodes auf der eigenen Webseite (Tipp von @mjustin) trage ich mich auch schon länger rum. Werde mir Google Cloud Run und Azure daher unbedingt auch noch anschauen - diese Möglichkeit kannte ich noch nicht, sie macht die Sache sicher nochmal wesentlich einfacher: Mir bliebe nur ein schickes Web-Interface zu programmieren, während der eigentliche "Rest" von der bereits fertigen Java-Lib in der Cloud erledigt würde. Danke für den Tipp!

Es würde mich freuen, wenn der eine oder andere die Bibliothek einmal testen möchte und mir eine Rückmeldung gibt, ob sich die Lib genau so einfach wie andere Bibliotheken auf GitHub/Maven in das eigene Projekt einfügen und dort verwenden lässt.

Ansonsten freue ich mich weiterhin auf Tipps jedweder Art.

 

[White_Fox]

Hauptziel ist (zur Erinnerung) die Promotion meiner Website.

Ich wüßte nicht, warum du deine Webseite nicht etwas auffälliger auf deiner github-Projektseite verlinken solltest (oder hat github etwas dagegen)?

Ansonsten freue ich mich weiterhin auf Tipps jedweder Art.

Was ich noch sehr schätze sind Codeschnipsel zum Einbinden, die man einfach kopieren und in seine build-Datei einfügen kann. Im Prinzip so, wie es auf der sonartype-Seite schon vorgemacht ist. Das spart halt das Besuchen der Sonartype-Seite.

 

[inflamer]

@White_Fox. Die Seite is

Ich wüßte nicht, warum du deine Webseite nicht etwas auffälliger auf deiner github-Projektseite verlinken solltest (oder hat github etwas dagegen)?

Was ich noch sehr schätze sind Codeschnipsel zum Einbinden, die man einfach kopieren und in seine build-Datei einfügen kann. Im Prinzip so, wie es auf der sonartype-Seite schon vorgemacht ist. Das spart halt das Besuchen der Sonartype-Seite.

Die Website ist ja - weiter unten auf der GitHub-Seite - bereits verlinkt, mit einem Hinweis auf das Tutorial, und damit an einer recht passenden Stelle, von der aus die User einem solchen Link vermutlich noch am ehesten folgen werden.

Bzgl. Schnipsel: Ja, kam mir auch schon als Idee in den Sinn, da überlege ich allerdings noch, weil dann ja auch Gradle & Co. mit berücksichtigt werden müssten und außerdem bei jedem neuen Release die Schnipsel angepasst werden müssten...

* * *

Erfreulich ist indes, dass Maven Central sowohl der Projektseite als auch der GitHub-Seite jeweils einen "vollwertigen" no-nofollow-Link gönnt.

 

[White_Fox]

Bzgl. Schnipsel: Ja, kam mir auch schon als Idee in den Sinn, da überlege ich allerdings noch, weil dann ja auch Gradle & Co. mit berücksichtigt werden müssten und außerdem bei jedem neuen Release die Schnipsel angepasst werden müssten...

Keine Ahnung wie das bei Maven ist, aber Gradle kann selbständig nach der neusten Version suchen:

Declaring Versions and Ranges

Da muß man nicht selber ständig etwas anpassen.