Comment créer et publier une bibliothèque Java utile

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 un permutationspackage 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?

• 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!

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:

repositories {
    mavenCentral()
    maven { url "https://jitpack.io" }
}

puis votre référentiel GitHub en tant que dépendance:

dependencies {
    // ...
    compile 'com.github.YourUsername:Repo:Release'
}

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 plupart des bibliothèques que je vois ont ce nom de package compliqué, notamment en ce qui concerne com / org. Y a-t-il une convention pour ces derniers ou un paquet de permutations est-il suffisant?

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 permutationpackages. 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.

Existe-t-il un format spécifique pour les publier? Dois-je inclure des fichiers WAR séparés pour le code source / javadoc?

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.

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?

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