quarkusio/quarkus

Document and expose documentation of BuildItems in an automated fashion

Open

#6.983 geöffnet am 4. Feb. 2020

Auf GitHub ansehen
 (8 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Java (2.464 Forks)batch import
good first issuekind/enhancement

Repository-Metriken

Stars
 (12.967 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 6T 4h) (325 gemergte PRs in 30 T)

Beschreibung

A big value of extensions is the BuildItem model. We need to document them so other extension writers can discover and use them. They are also part of the extension contract.

  1. document all "public" BuildItem with adequate JavaDoc
  2. build an anotation processor that will collect the BuildItems and generate a list of them per extension and a documentation (summary?).

Contributor Guide

Research-Richtung
Studieren Sie vorhandene BuildItem Klassen und deren JavaDoc, entwerfen Sie dann einen Annotationsprozessor, um eine Liste von BuildItems pro Erweiterung zu sammeln und zu generieren. Erwägen Sie die Verwendung des Pakets javax.annotation.processing oder ähnlicher Tools.
Tech Stack
java
Domain
backenddocumentation
Issue Type
Dokumentation
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
JavaMaven or GradleAnnotation processing
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
65