J'ai récemment travaillé sur une classe Java qui génère des permutations par liste d'objets. Dans tous les cas, j'aimerais que cette bibliothèque soit offerte au public, j'ai donc plusieurs questions:
- La plupart des bibliothèques que je vois ont ce nom de paquet compliqué, incluant spécifiquement
com
/org
. Existe-t-il une convention pour ces derniers ou unpermutations
package est-il suffisant? - Existe-t-il un format spécifique pour les publier? Dois-je inclure des fichiers WAR séparés pour le code source / javadoc?
- J'ai les fichiers sur un référentiel GitHub. Je suppose que je peux y servir les fichiers, mais comment puis-je amener les gens à trouver mon repo?
java
open-source
libraries
Amir Rachum
la source
la source
amirrachum.util.permutations
pourrait être bon.Réponses:
Une façon standard de publier (en dehors du code source sur GitHub) est d'avoir des versions JAR / WAR formelles sur Maven Central que de nombreux outils de construction (Maven, Gradle, Ant / Ivy) utilisent pour intégrer des bibliothèques en tant que dépendance. Pour ce faire, la meilleure façon est de passer par le processus Nexus .
Il est également considéré comme convivial d'héberger ces mêmes fichiers JAR / WAR sur un référentiel d'hébergement de code tel que Sourceforge ou GitHub.
En termes de votre domaine. Je vous recommande d'acheter firstnamelastname.net/org/com et de l'utiliser comme schéma de dénomination (par exemple, pour moi, c'est net.martijnverburg.foobar). Sinon, utiliser le domaine github comme suggéré par @Daniel Moura est une bonne chose.
Pour le publier, bloguer à ce sujet, twitter à ce sujet, le soumettre aux nouvelles des pirates, reddit, digg, slashdot, dzone, TSS, javaworld, etc.
HTH!
la source
Si vous avez poussé votre code vers GitHub, partager votre bibliothèque (jar) est facile avec JitPack .
Vos utilisateurs n'auront qu'à ajouter le référentiel à leur build.gradle:
puis votre référentiel GitHub en tant que dépendance:
JitPack agit comme un référentiel Maven similaire à Maven Central. La bonne chose est que vous n'avez pas à télécharger votre bibliothèque. Dans les coulisses, JitPack vérifiera le code de GitHub et le compilera. Lorsque vous publiez une nouvelle version sur GitHub, elle devient disponible pour les autres utilisateurs.
Il y a aussi un guide sur la façon de préparer un projet et des exemples pour ajouter un pot de sources.
Il n'est pas nécessaire d'avoir un nom de domaine, donc votre groupId devient com.github.Username. Vous pouvez également l'utiliser pour nommer les packages.
la source
Il existe des recommandations d'Oracle sur la façon de nommer vos packages . La raison de cette convention de dénomination est de minimiser les doublons. Si tout le monde utilise simplement des noms courts et simples, il devient plus probable qu'un projet inclura deux
permutation
packages. Si un nom de classe était le même, il y aurait des conflits de noms. Les choses peuvent devenir déroutantes pour le développeur, s'il n'y a pas de conflits de noms qui empêchent la résolution des classes.Si vous avez un nom de domaine, je vous suggère de l'utiliser. Si vous hébergez sur un service tel que GitHub ou Sourceforge, utiliser le chemin d'accès à votre projet serait également suffisant. Quoi qu'il en soit, soyez explicite pour éviter les conflits ou la confusion.
Il n'y a pas de format spécifique. À tout le moins, source et un script de construction de convention (Make, Ant, Maven). C'est bien d'avoir des fichiers JAR ou WAR précompilés, mais ce n'est pas essentiel. Certains projets incluent le Javadoc dans la bibliothèque, d'autres peuvent produire deux fichiers JAR (un avec Javadoc et un sans). Il peut également être judicieux de publier simplement votre Javadoc sur Internet si votre solution d'hébergement de projet le permet.
Annoncez-le. Commencez par le montrer à quelques amis. Blog à ce sujet. Partagez un lien sur Internet. Trouvez quelqu'un qui a un problème qu'il peut résoudre en utilisant cette bibliothèque (mais assurez-vous de révéler que vous avez créé la bibliothèque).
la source