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

Inizia leggendo l’issue correlata #1204 e mappando il modo in cui processing-website, processing-doclet, processing-examples, processing4 e processing4-javadocs scambiano attualmente i contenuti generati. Esamina i passaggi esistenti di build e release prima di scegliere un percorso di migrazione. Il lavoro sarà considerato completato quando i repository non richiederanno più la co-localizzazione manuale né copie in sola lettura e le azioni documentate di generazione e aggiornamento saranno automatizzate o consolidate.