Documentation Revamp / Organisation

The examples and some of the documentation around Processing are kind of all over the place

The Goal

Have one repo where documentation lives: processing-website

The current issues

• processing-website
  • updates processing4's keywords.txt based on content generated through processing-doclet
  • has to manually update content/examples and it is unclear that this data is partially read-only, the script applies processing-examples on top
  • content/contributions is also readonly and is no longer compatible with the new processing-contributions pipeline
• processing4-javadocs does not automatically update with each release
• processing-examples does not contain the images/livesketches/metadata that the website needs.
• processing-doclet is a separate repo that will create the parsed javadoc comments for the website

Suggested actions

• Get rid of any instances where the developer has to make sure repositories live next to each other on disk
• Migrate processing-doclet into the processing-website and make it run on build
  • Research further into migrating / replicating the custom doclet into Gradle and make it run w gradle
• Delete processing-doclet repo
• Migrate processing-examples into the processing-website
  • Tested, still need to figure out how to merge the folders whilst keeping history
• Archive processing-examples
• Remove all read-only files from processing-website
• Move the generation of keywords.txt back into the processing4 repo
• Add an automatic update trigger for processing4-javadoc to the processing4 repo release action (or migrate processing4-javadoc into the processing4 repo)
  • Migrate Javadoc from Ant to Gradle

Related PRs/Issues/Other documentation

#1204

Commencez par lire l’issue associée #1204 et par cartographier la manière dont processing-website, processing-doclet, processing-examples, processing4 et processing4-javadocs échangent actuellement le contenu généré. Examinez les étapes existantes de build et de release avant de choisir une voie de migration. Le travail sera considéré comme terminé lorsque les dépôts n’exigeront plus de co-localisation manuelle ni de copies en lecture seule, et que les actions documentées de génération et de mise à jour seront automatisées ou regroupées.