On 17 April 2018 at 15:03, Jan Iversen <j...@apache.org> wrote: > > > Sent from my iPad > >>> On 17 Apr 2018, at 14:52, sebb <seb...@gmail.com> wrote: >>> >>> On 17 April 2018 at 13:35, Jan Iversen <j...@apache.org> wrote: >>> >>> >>> Sent from my iPad >>> >>>>> On 17 Apr 2018, at 14:22, sebb <seb...@gmail.com> wrote: >>>>> >>>>> On 17 April 2018 at 13:04, Jan Iversen <jancasacon...@gmail.com> wrote: >>>>> >>>>> >>>>>> On 17 Apr 2018, at 13:55, sebb <seb...@gmail.com> wrote: >>>>>> >>>>>> On 17 April 2018 at 11:59, Jan Iversen <j...@apache.org >>>>>> <mailto:j...@apache.org>> wrote: >>>>>>> >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>>>> On 17 Apr 2018, at 12:53, sebb <seb...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On 15 April 2018 at 10:42, Jan Iversen <j...@apache.org> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from my iPad >>>>>>>>> >>>>>>>>>>> On 15 Apr 2018, at 11:37, sebb <seb...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> On 15 April 2018 at 10:03, <j...@apache.org> wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> Please have a look at >>>>>>>>>>> http://attic.apache.org/test.html >>>>>>>>>>> <http://attic.apache.org/test.html> >>>>>>>>>>> >>>>>>>>>>> This is a “new” homepage. The only real new thing is that I got rid >>>>>>>>>>> of “ant” and sidebar/project pages are generated in Javascript. >>>>>>>>>>> This makes maintenance for me a lot easier. >>>>>>>>>> >>>>>>>>>> It looks fine. >>>>>>>>>> However if Javascript is disabled, the sidebar is missing, but there >>>>>>>>>> is no indication that this might be so. >>>>>>>>>> >>>>>>>>>>> As a side effect, we got a json list (in scripts/attic.js) of all >>>>>>>>>>> projects, that might be useful for other purposes. >>>>>>>>>>> >>>>>>>>>>> Please feel free to correct/amend especially the project list. >>>>>>>>>> >>>>>>>>>>> If nobody objects I will put it in production later and cleanup the >>>>>>>>>>> site. >>>>>>>>>> >>>>>>>>>> I would rather see the JSON file used to generate a static site. >>>>>>>>> I agree on that, but with the limitations, the only solution would be >>>>>>>>> a build job, that somehow triggers on svn commit. I have no >>>>>>>>> experience with that but patches are welcome. >>>>>>>> >>>>>>>> I have created INFRA-16384 >>>>>>>> >>>>>>>> The test.html page and script mostly work well, however AFAICT there >>>>>>>> is as yet no support for the existing URLs, e.g. >>>>>>>> http://attic.apache.org/projects/abdera.html. These must continue to >>>>>>>> be supported. >>>>>>> why is that a demand, they have no function as such. >>>>>> >>>>>> Because they are referenced elsewhere. >>>>>> For example oltu.apache.org <http://oltu.apache.org/> links to >>>>>> https://attic.apache.org/projects/oltu.html >>>>>> <https://attic.apache.org/projects/oltu.html> >>>>>> And the existing index page publishes links to the summary pages. >>>>>> >>>>>> URLs should not be abandoned without good reason >>>>> Well easier maintenance is an excellent reason seen from my POW (as I am >>>>> the one who have done all the retirements since I joined the project). >>>> >>>> There are other ways to simplify maintenance without breaking URLs. >>> I did not find an easier way, but you are welcome to make another >>> suggestion. >>>> >>>>> And a simple .htaccess with a redirect to a common page can solve the >>>>> link problem. Something which is a good idea, once we have activated the >>>>> new setup. >>>> >>>> However that would generate more URLs that have to be maintained if >>>> the site generation changes again. >>> >>> how come? the .htaccess would have a wildcard redirecting to projects.html, >>> with the original url as parameter that way it would be a oneliner >>> extension of the existing script.....and more importantly not something >>> extra to do for each retirement. >> >> Assume the redirection is to something like: >> >> projects.html?oltu >> >> That means there is now a new set of URLs. >> If the way the site is generated changes again some way will have to >> be found to continue to honour the URLs. > > that really depend how you look at it. > attic.apache.org/projects/oltu.html would respond with the redirect, so in > that sense the only change is in svn. > >> >> URLs are part of the public API of a site. > the url yes, the physical file no. > > I did make the changes which you requested that makes sense to me. Please > remember in this case I am the “doer”, and made a solution to make > maintenance easier. > > I do not want this be a lengthy debate like we had on the “dist” issue. There > are also now a competing solution from you, it currently does not simplify > anything like e.g. use projects.json so it is not really helping now. For > those reasons I believe it is better to forget my javascript solution. > > Another reason for my javascript solution was to be able to do the attic work, > when I only have access to my ipad. From start may to end september that is > the case, I hope somebody will step up and do the job the old fashioned way > if needed (only retirements if any).
Is your iPad able to edit files and commit them? e.g. if there was a projects.json file could this be updated in SVN? > Sorry for trying to modernize a very outdated maintenance model on purpose > without changing the external look/access. The new files are not in > production, so I will do a simple “svn rm” and stop wasting mine and others > time. I agree it's long overdue to simplify the process. However I think the replacement needs to retain existing URLs and be easier to maintain. My experience is that using JS + HTML is not particularly easy to work with, as well as requiring JS on the client. I think it's a non-starter to try and modify the existing generation to pick up the data from JSON or XML. So I've started looking at Jekyll, and that looks promising. It creates static sites and can process data from JSON files. And it is already used by Buildbot e.g. for Flink. > Rgds > Jan I. > >> >>> >>> rgds >>> jan i >>>> >>>>>> . >>>>>> >>>>>>>> I'm not sure that is easy to do with client-side Javascript. >>>>>>>> >>>>>>>> [There is no code currently to customise the text "... choose to fork >>>>>>>> ACE ...".] >>>>>>> Easy done, I simply overlooked it. >>>>>>>> >>>>>>>> The JSON file needs to be extended to cater for customised project >>>>>>>> pages, such as >>>>>>>> http://attic.apache.org/projects/abdera.html >>>>>>>> <http://attic.apache.org/projects/abdera.html> >>>>>>>> which has details of related projects. That should be easy enough. >>>>>>> I politely disagree to this, that page e.g. contains a link to dist >>>>>>> which are cleaned. >>>>>> >>>>>> No idea what you mean by the reference to dist and cleaning. >>>>>> >>>>>> The page contains references to other projects which I think need to be >>>>>> kept. >>>>> That is no problem, add the text you want kept to the json object in >>>>> field “description”. >>>>> >>>>>> >>>>>>> I strongly believe it is a lot better that all project pages follow the >>>>>>> same template, project individual information are contained on the old >>>>>>> <project>.apache.org <http://apache.org/> page. >>>>>>> >>>>>>> And btw all newer project pages follow the template I made. >>>>>> >>>>>> Some examples? >>>>> Oltu just to mention the very newest. In fact it is only very old ones >>>>> who have an extra description and as mentioned above, if you have those >>>>> simply add the text to json. >>>>> rgds >>>>> Jan I. >>>>>> >>>>>>> rgds >>>>>>> jan i >>>>>>> >>>>>>>> >>>>>>>> Ideally the output from the new process should be compared with the >>>>>>>> existing output before switching over. >>>>>>>> >>>>>>>>> rgds >>>>>>>>> jan i >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> rgds >>>>>>>>>>> Jan I >>>>>
