Just so this isn’t left dangling any longer, I came up with https://github.com/apache/camel-website/pull/673 which - uses Antora to generate the components/latest to components/3.13.x redirects, - Adds some modified redirectMatch rules to redirect components/ to components/3.13.x - merges this into the static/.htaccess, removing some old stuff from camel-quarkus and Zoran’s manually written rewrite rules.
This also lets camel projects use the page-aliases feature. David Jencks > On Nov 2, 2021, at 2:23 AM, Zoran Regvart <zo...@regvart.com> wrote: > > Hi David, > I'm a bit confused as to what are we trying to achieve here, redirect > <component>/latest to <component>/<actual latest>, e.g.: > > /camel/components/latest to /camel/components/3.12.x > > Am I on point thus far? Some questions below: > > On Sun, Oct 31, 2021 at 4:26 PM David Jencks <david.a.jen...@gmail.com > <mailto:david.a.jen...@gmail.com>> wrote: >> >> I looked into this a little bit, using the Antora 3 `latest-version-segment` >> feature: >> >> urls: >> redirect_facility: httpd >> latest_version_segment_strategy: redirect:from >> latest_version_segment: latest >> >> This generates the following in the generated .htaccess: >> >> Redirect 302 /manual/latest /manual >> Redirect 302 /components/latest /components/3.12.x >> Redirect 302 /camel-k/latest /camel-k/1.6.x >> Redirect 302 /camel-kamelets/latest /camel-kamelets/next >> Redirect 302 /camel-quarkus/latest /camel-quarkus/2.4.x >> Redirect 302 /camel-kafka-connector/latest /camel-kafka-connector/0.11.0 >> Redirect 302 /camel-spring-boot/latest /camel-spring-boot/3.12.x >> Redirect 302 /camel-karaf/latest /camel-karaf/3.12.x >> - I think in any case we should use Redirect rather than Rewrite as in fact >> we want to generate redirects. > > Both generate a HTTP redirect, and by that I mean 3xx status and a > `Location` header, what am I missing here? Btw I would also use > `Redirect`, it seems easier to follow and maintain. > >> - I think we should use 302 rather than 301 since these redirects will >> change as we release newer versions. > > +1 and I think we should do this for both `.../next` and `.../latest` URLs > >> - I think that a RedirectMatch rule that redirects <project>/<not concrete >> version or `next`>/ to the same target is likely to work: such a rule can >> easily be generated from the above. > > Do we need to? Couldn't we use the above generated .htaccess file directly? > >> So I’m thinking: >> >> - extract the above from the generated .htaccess >> - transform to the <project> >>> <project>/<latest concrete release> form, >> and add to generated .htaccess >> - insert the generated .htaccess in an appropriate place in static .htaccess > > Would Antora generate the .htaccess file in the root of the website > (i.e. in `documentation` and then copied over to `public`) when built, > so it would overwrite the existing .htaccess file from static? If not, > i.e. it would generate a .htaccess file per Antora component, we could > just leave those there. > >> I don’t have any good ideas yet on how or where to do this. I imagine the >> gulp file would be a good place but I’m not an expert on having gulp >> transform individual files. > > So, if I'm understanding this right, the problem is that the two (or > more?) .htaccess files would be generated in the same location and end > up overwriting each other. In that case we would need some way of > merging them and that we can do using Gulp. > > Another idea could be to add a Hugo template with similar logic as we > do on the download page and generate the desired .htaccess file. The > downloads page is fed via the release note's front matter and _if_ we > make sure that the documentation is ready for a release, which hasn't > been the case for 100% of the releases thus far, that's an approach > that can be made to work. > > zoran > -- > Zoran Regvart
