eclipse.platform.releng.aggregator
eclipse.platform.releng.aggregator copied to clipboard
php deprecation download.eclipse.org
see https://www.eclipse.org/lists/cross-project-issues-dev/msg19988.html:
PHP is also deprecated on download.eclipse.org, but you have until the end of 2025 to make those changes.
What will happen to testResults.php? linked in
https://download.eclipse.org/eclipse/downloads/index.html
i.e. https://download.eclipse.org/eclipse/downloads/drops4/I20241212-1800/testResults.php
If no one steps up to redo it (note that would be big task as it's very convoluted) my plan is to do the minimum to get only p2 repos published and everything else will have to be figured out/reported in Jenkins UI. If someone steps up - what and how it would look like would be more or less up to them.
https://gitlab.eclipse.org/eclipse-wg/ide-wg/steering-committee/program-plan/-/issues/49
https://gitlab.eclipse.org/eclipse-wg/ide-wg/steering-committee/program-plan/-/issues/49
This gives me 404, is the link wrong?
It's maybe not public.
sorry, ide wg members only. just a remark that i raised question to IDE working group.
Hi, asking @denisroy about this question, he was mentionning that testResults.php could likely be run in a Jenkins job, and the static results can be published in html format to download.eclipse.org (and btw telling me that the project can ask for some basic support in a HelpDesk issue), wdyt?
created https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5439
Hello Everyone,
Since PHP support for the download and archive pages will be deprecated by the end of 2025, this discussion focuses on how to address that situation. A mechanism will definitely be needed to handle it, and JavaScript could be a viable solution, potentially using a front-end library or framework like React or Angular.
If we proceed with the JavaScript approach (or any other approach), will the code be maintained in the Releng repository itself? Additionally, if web APIs are needed (it’s unclear if the current download/archive pages rely on PHP-based APIs), what would be the best alternative? Should we consider Node.js or another scripting language?
Note: After reviewing some of the webpages under download.eclipse.org, it seems that an implementation based solely on HTML and CSS would not suffice.
I’m eagerly awaiting suggestions and opinions from the community members.
@BeckerWdf @HannesWell @laeubi @vogella @MohananRahul @mickaelistria @mpalat
I guess the solution depends on the particular page. I'm not found of more complex JavaScript frameworks everywhere. Additionally to the maintenance burden it can be, JavaScript is usually much more expensive than PHP: ie to generate 1 full page with JavaScript, a lot of different files need to be fetched from server to then be processed on client side. That's very "brown-IT" (as opposed to green IT).
I see https://download.eclipse.org/eclipse/downloads/index.html is fairly dynamic (updated on each build) and yet fully uses HTML. This can be used an example. How is this page generated and refreshed on each build? Is PHP called as part of the CI process to generate HTML?
I see some importants pages that use PHP (for each build):
- https://download.eclipse.org/eclipse/downloads/drops4/I20250105-1800/index.php , which could probably be an html page, updated whenever a test job completes
- https://download.eclipse.org/eclipse/downloads/drops4/I20250105-1800/testResults.php, which could probably be an html page, updated whenever a test job completes
- https://download.eclipse.org/eclipse/downloads/drops4/I20250105-1800/buildlogs.php, which could probably be an html page, updated when the build job complete
- https://download.eclipse.org/eclipse/downloads/drops4/I20250105-1800/logs.php#console, which could probably be an html page, updated when a test job complete
Yes, I think eventually everything in the download area of the Eclipse-SDK can be static HTML side that is updated by the corresponding build/test job when they have completed. Like it is already down similiarly.
Please see also the discussion at https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/discussions/2715 respectively my answer at https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/discussions/2715#discussioncomment-11742908
We have now https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/2906 which makes it very hard for everyone involved to trace platform build state.
It would be great if we could help there ASAP as a first step getting rid of php.
As there has been another warning from the EF infra team about the final PHP fade-out by the end of this/beginning of next year, I wanted to let you know that I plan to work on the migration of the Eclipse download pages soon, in the way I suggested in
- https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/discussions/2715#discussioncomment-13383798
unless somebody has a better proposal or plans to work on this.