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.
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 ? ;)
- 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
> >>
>
