Hi - My progress is slower than I hoped.
I have a handle on conversion of the xml pages to GitHub Flavored Markdown by adapting Forrest’s Anakia2Markdown plugin. There are still some xml elements to translate. TODOs are: - Menu generation from sitemap. - Changes/Status page generation. - New template based on template-site… - FAQ page - manual conversion will be done. It’s a one off. > On Jul 13, 2021, at 10:56 AM, Dave Fisher <w...@apache.org> wrote: > > Hi - > > I’ve had two git repositories created: > > poi-site and poi-xmlbeans-site > >> On Jul 11, 2021, at 1:31 PM, Andreas Beeker <kiwiwi...@apache.org> wrote: >> >> Hi Dave, >> >>> A simpler way of stating (b) is that we separate the site from the release >>> process. This makes sense to me since since there are portions of the site >>> like download pages that should be changed after the release package has >>> been made. >> Ok +1 for this >> >>> If there are portions of the site that should be versioned with the release >>> and apidocs then we should probably work to include those pages with the >>> apidocs. I vaguely recall that it is possible to extend the apidocs to >>> include other files. >> I'm fine with it, but I think we hardly make use of it - here is how to do >> it: >> https://stackoverflow.com/questions/10779169/including-images-in-javadocs >> <https://stackoverflow.com/questions/10779169/including-images-in-javadocs> >> WRT Pelican vs jBake: >> I'm leaning towards jBake, because I'm not sure, if I need to do python >> modifications with Pelican, which skills I'm lacking. >> > It is likely that no custom python plugins will be required and everything in > the sites will be markdown, html, css, and javascript. > > Pelican uses JINJA templates for the base. > > Should a new Pelican Plugin be needed I will push to include it in > infrastructure-pelican and it will be Infra that will maintain it. >> On the other hand, the markdown source is clear and simple. >> So I would say, Dave, make up your mind and choose what you think fits best. >> I think the POI PMC can handle both. >> > I’m going to lean towards Pelican for now. > > There is a plugin for Forrest that supposedly will make mdtext files during a > forrest build. If that works then this will be pretty quick. >>> I’ll need to refine the OpenOffice Pelican scaling issue. I suspect that >>> the logo is the issue. Did you use a tool? If so, what? >> No tool - I need to scale most pages to 200% because of an 1:1 scaling on my >> hidpi / wayland gui. >> With openoffice the menu text only zooms marginally whereas the blue bar >> behind it zooms linear. >> The drop down menus are then scaled too much. >> >> <ajoknlmnfimnblbo.png> >> >> > > This looks like a bad mix of pt, px, and rem in the css. Thanks! >> >>> WRT Javadocs, not sure if I understood you right, but I assume we still >>> generate the docs with the javadoc default layout of the active (= as set >>> in the environment) JDK and update the POIs minor version directory with >>> it. If jBake/Pelican complains about a missing link here, we still can use >>> external links and replace them with local links via gradle for the >>> archives. >>> Sure. One question is whether or not we wish to retain every version of >>> javadocs in the site. >> A while back we decided to keep and update the minor versions. >> Eventually we might want to remove obsolete javadocs, but we haven't >> discussed on this. >> >>> Is the following still accurate: >>> https://svn.apache.org/repos/asf/poi/site/README.txt >>> <https://svn.apache.org/repos/asf/poi/site/README.txt> >>> <https://svn.apache.org/repos/asf/poi/site/README.txt> >>> <https://svn.apache.org/repos/asf/poi/site/README.txt>? >> No this is not uptodate. "gradle site" and "ant site" only work with Java 8 >> and maybe eventually we would like to skip that version. >> After the java-/docs are generated, I copy/commit them to the svnpubsub >> branch. >> > So we can do this to the new git repositories instead. That should be easy to > script. > >> WRT XmlBeans: I use "ant site" in the site branch and commit the >> "./build/site" artifacts. >> >>> I can work in parallel with either jBake or Pelican in GitHub producing >>> poi.staged.apache.org <http://poi.staged.apache.org/> >>> <http://poi.staged.apache.org/> and xmlbeans.staged.apache.org >>> <http://xmlbeans.staged.apache.org/> <http://xmlbeans.staged.apache.org/> >>> until we are ready to shift. I’ll wait a few days before requesting two git >>> repositories to see if there are other ideas. >> Is *.staged.apache.org already the live site? If not, how does the staging >> to the live site work? >> >> > > See > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features > <https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features> > > The staged sites will be poi.staged.apache.org > <http://poi.staged.apache.org/> and poi-xmlbeans.staged.apache.org > <http://poi-xmlbeans.staged.apache.org/> > > We can actually put the apidocs into their own branch and publish as subdirs. > You can look at the branches of GitHub.com/apache/openjpa for an example. >> If you start converting the forrest xmls to either >> jBake(groovy)/Pelican(md), please have a look at the changes.xml soon, as >> this might need some scripting. Also the formatted code parts would be nice >> to have. >> > Certainly. I’m thinking we can use a client side highlighter. See > https://highlightjs.org >> I'm now progressing with the src/bin archives without the site files in our >> gradle script. >> > Great. > > All the best, > Dave >> Andi. >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
