On 08/03/2020 12:40, Roy Lenferink wrote:
On 2020/03/08 10:29:17, Andy Seaborne <[email protected]> wrote:
On 08/03/2020 09:40, Roy Lenferink wrote:
Hi Andy,
Good to be pro-active on this! However, I had yet to send reply to this list
that the actual move was
already done :) See [1] for the actual change.
:-)
To verify: on jena.a.o the 'Edit this page' button is visible (meaning the site
is served from Git), and
this correctly redirects the user to the jena-site repository on GitHub.
Yes - "edit" is there.
https://jena.apache.org/documentation/javadoc/ was 404.
Fixed by change the layout but (for future reference), is it possible to
have content in :master:/documentation/javadoc/_index.md and then not
have it lost when branch javadoc is gitpubsub'ed. i.e does the
additional javadoc branch simply copy in more HTML pages or replace the
directory?
If it is copy-in, I'll change the change to preserve bookmarks.
Only a single source of truth is preserved. It is not possible to retain both.
I discussed this with infra
(for MINA) on Slack here:
https://the-asf.slack.com/archives/CBX4TSBQ8/p1582565890030900
However something I am investigating and that possibly can be useful for Jena
is to have a
virtual domain 'docs.jena.apache.org' in place which will be served using e.g.
a branch called
'jena-docs' (instead of javadoc). DNS won't be in place so people cannot visit
docs.jena.apache.org.
Using RewriteRules (.htaccess) the exact location of the documentation can be
preserved.
In that case we can change URLs to let
https://jena.apache.org/documentation/javadoc/
function again.
A simple setup is robust over time so a few changes that keep things
straightforward are good. Having all the special index pages pulled out
of the javadoc tree is actually helpful because you can delete/reset all
the javadoc cleanly. As an RM, I can say it's one less mistake to make!
You've converted the Elephas one anyway (I'll check for any others).
https://jena.apache.org/documentation/javadoc/ => content served from asf-site
branch (generated
with Hugo)
http://jena.apache.org/documentation/javadoc/jena/ => served because a
.htaccess (present on the
asf-site branch) contains a RewriteRule to
docs.jena.a.o/documentation/javadoc/jena/
Lucene does the same.
Is polling scm (build job) something we want to set-up or are starting with
manually triggering the
build-job after changes are made?
Personally, I'd prefer to change to polling SCM.
We have typically published the site with the release, having used
"staging" to view changes. trunk had the role of "proposed".
If everyone is happy and setup for Hugo, we can change to master being
the ready-to-go real thing.
Personally I'd say to have the polling in place. This ensures the latest
changes will always be in
place. Why would we want to have something on the master branch but not served
on the site ? ;)
Ack.
Andy
- Roy
Andy
[1] https://github.com/apache/infrastructure-puppet/pull/1734
On 2020/03/08 08:55:37, Andy Seaborne <[email protected]> wrote:
Request made to move from svn+CMS to gitpubsub:
https://issues.apache.org/jira/browse/INFRA-19939
Andy
