Générer la javadoc uniquement avec JRE

Question

J'aimerais pouvoir générer la javadoc pour mes projets maven même lorsqu'ils sont exécutés sous un JRE au lieu d'un JDK, où se trouve la commande javadoc invoquée par maven. En d'autres termes, ne pas s'appuyer sur autre chose que ce qui se trouve dans le JRE et ce que Maven peut télécharger et utiliser comme artefacts.

Existe-t-il un moyen simple de générer des javadocs avec Maven sans avoir à utiliser du code qui se trouve uniquement dans le JDK ?

---

EDIT : Apparemment il est important de comprendre por qué Je veux le faire. Nous sommes une petite équipe au sein d'une grande organisation qui publie des versions annuelles de sa suite de produits, que nos clients mettent ensuite à niveau quand cela leur convient (en raison de l'ampleur des déploiements, cela coûte cher et prend du temps, il est donc courant de sauter une ou plusieurs versions) et nous gagnons notre vie en étant capables de fournir des corrections de bogues et de nouvelles fonctionnalités à court terme pour les déploiements existants, quelle que soit la version utilisée par le client en question. Par exemple, j'ai récemment corrigé un bogue pour un composant que j'ai écrit il y a cinq ans et qui n'avait pratiquement pas été modifié depuis.

La stabilité à long terme de notre processus de construction est donc très importante pour nous, tout comme la possibilité d'utiliser les nouvelles versions de Java dès qu'elles sont disponibles. Nous avons migré l'ensemble de notre environnement de construction vers Maven - ce qui nous permet d'avoir des artefacts gelés en permanence dans Maven Central - et nous avons maintenant commencé à examiner ce que nous devons faire d'autre.

Avec l'annonce récente que les futures versions de javac ne supporteront pas les anciennes cibles ( http://openjdk.java.net/jeps/182 ), nous avons conclu que notre objectif à long terme est de réduire au minimum nos dépendances à l'égard de l'environnement Java sous-jacent, de préférence au simple JRE. Nous sommes en train de remplacer complètement javac du JDK par le compilateur Eclipse qui est disponible à partir de Maven Central, et maintenant nous nous penchons sur la génération de javadoc.

Answer 1

Obtenez la source de la JavaDoc de l'OpenJDK et construisez votre propre JAR à partir de celui-ci avec toutes les classes JavaDoc pertinentes. Rédigez un maven qui repose sur votre JAR, et appeler com.sun.tools.javadoc.Main.main d'elle.

Il ne semble pas que Vous devez ouvrir vos sources lorsque vous utilisez les classes d'OpenJDK. vous devriez pouvoir distribuer le plug-in qui en résulte sans trop de restrictions.

Même si les termes ne couvrent pas les outils, vous pouvez écrire un plugin Open Source GPL-2 pour les outils suivants maven et en faire un produit séparé que vous distribuez sous GPL-2. Votre produit pourra alors télécharger et installer le plugin en utilisant la commande maven plugin:download , séparant ainsi votre plugin JavaDoc du reste de votre code.

Bien entendu, vous devez soumettre cette suggestion à votre service juridique avant de suivre ce conseil.

Answer 2

1. Un aparté (sans répondre directement à votre question) :

   Le guide de développement Eclipse recommande d'utiliser à la fois le compilateur Eclipse et l'outil JDK (pour l'option de menu javadoc).

   http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-export-javadoc.htm

   Assistant Eclipse Generate Javadoc : qu'est-ce que la "commande Javadoc" ?

   D'après vos commentaires, il est clair que vous ne voulez pas suivre cette voie, ce qui est votre droit :)

2. Réponse à votre question : il existe quelques outils javadoc gratuits ou open source que vous pouvez invoquer à partir de votre outil de construction :

   • Major

     • Doxygen

       Doxygen et Javadoc
       http://doodleproject.sourceforge.net/mavenite/doxygen-maven-plugin/

     • Docflex Doclet (nécessite JDK)

       http://www.filigris.com/print.php?printfile=/products/docflex_javadoc/docs/integrations.php#maven_2.2.x_3.0.x

   • Mineur

     • Javadoc2Help

       (créer votre propre commande/plugin maven ?)

     • Javadoq

       (créer votre propre commande/plugin maven ?)

   Pour : Travailler en dehors du JDK. Certains ont une documentation plus riche que javadoc.
   Inconvénients : certains comportements non standardisés par rapport à la javadoc (cela peut ne pas être un problème pour vous).

Answer 3

Vous pouvez utiliser un produit appelé doxygen . Il est généralement utilisé pour créer de la documentation pour le C++ ou d'autres langages qui ne disposent pas d'un langage de base. javadoc produit intégré.

Vous pouvez configurer doxygen pour qu'il lise les annotations de javadoc et produise un résultat similaire à celui de javadoc.

Answer 4

La commande qui génère les documents java s'appelle en fait javadoc et il n'est disponible qu'avec le JDK.

Answer 5

Nous proposons un outil appelé DocFlex/Javadoc qui a déjà été mentionné aquí par Glen Best (bien que de manière un peu incorrecte).

Mais avant d'entrer dans le vif du sujet, je voudrais vous donner une introduction à ce dont il s'agit.

Fondamentalement, Javadoc (qui est fourni par le JDK) est un appel de deux choses :

1. L'analyseur syntaxique Java
2. Un doclet

Javadoc commence par appeler l'analyseur syntaxique Java pour collecter des informations sur les sources Java, à partir desquelles il construit un fichier DOM -représentée sous la forme de API Doclet . Ensuite, il appelle un doclet . Il s'agit d'un plug-in Javadoc qui utilise l'API Doclet comme source de données pour générer tout type de résultat.

Ce que vous voyez comme étant le JavaDoc standard est généré par les Doclet standard . Vous pouvez donc imaginer que le doclet est la partie la plus importante de l'implémentation de Javadoc.

Maintenant, à propos de notre DocFlex/Javadoc logiciel. Essentiellement, il s'agit d'un outil de développement rapide de doclets spéciaux, qui utilise notre technologie beaucoup plus générale pour les générateurs de documentation basés sur des modèles. (En fait, notre objectif est plutôt éloigné des questions de Javadoc. Il s'agit donc plutôt d'un sous-produit de l'activité principale).

Dans notre interprétation, les doclets eux-mêmes (en tant que générateurs de documentation) sont programmés sous la forme d'ensembles de modèles spéciaux. Ces modèles ressemblent davantage à des scripts XSLT, mais uniquement sur le plan conceptuel (nous n'utilisons pas XSLT en arrière-plan). L'organisation DOM de l'API Doclet nous a permis d'utiliser une approche XSLT/XPath-like générale à notre technologie. Ainsi, chaque doclet se compose de deux éléments :

1. L'interpréteur de modèles
2. Un ensemble de modèles

Ici, le ensemble de modèles est une pièce interchangeable (ce qui est en fait l'objectif de notre outil).

Actuellement, nous fournissons une solution prête à l'emploi JavadocPro qui génère une sortie HTML équivalente aux JavaDocs standard (avec quelques fonctionnalités supplémentaires importantes non disponibles dans le Doclet standard). Ici, vous pouvez voir un Démo JavaDoc généré avec elle :

L'ensemble DocFlex/Javadoc est un produit commercial. Mais nous en fournissons également une édition légère appelée DocFlex/Doclet qui est gratuit. Il ne comprend qu'un interpréteur de modèles et quelques jeux de modèles prêts à l'emploi (dont JavadocPro ). Vous pouvez donc l'utiliser pour générer une documentation JavaDoc très similaire à la documentation standard (en HTML) ainsi qu'une documentation RTF.

---

Maintenant, concernant la question principale. Notre outil peut-il être utilisé sans JDK ?

Non. Parce que, étant un plug-in Javadoc (la partie doclet de notre outil), il a toujours besoin de Javadoc.

En revanche, ce qui manque pour le rendre totalement indépendant du JDK est un analyseur syntaxique Java, et nous n'avons pas besoin d'un analyseur Java complet, car nous ne générons pas de code exécutable. Ce dont nous avons besoin, c'est de quelque chose de léger, capable de construire une structure comme l'API Doclet.

Si nous savions quelle est la demande pour une telle chose, nous pourrions envisager d'en développer une. Vous avez d'autres questions ? Faites-nous en part par courrier électronique (que vous trouverez sur notre site web ) !