That folder's web page "redirects" to the index file of the folder via standard rules for finding an index.* of some sort in the folder, so this index.php serves the contents:
Any query parameters on the URL, i.e., project=..., are interpreted by the PHP of the page. (And I'm no big PHP expert, so where exactly this is being done is not currently clear to me; in JustJ's pages I use $page = $_GET["page"]; to get the value of the page query parameter.)
So probably it's good that you figure out how to do this for mmt because doing it for modeling is likely very similar.
And note that I don't believe there is any stomping involved because there is no mmt folder in the modeling project so this page/folder does not exist:
No. MMT (and its sub-projects) have yet to be re-gitified; still git.eclipse.org:29418/www.eclipse.org/mmt.git. Just like the modeling root which has/had not been regitified contributing to difficulties working out what happens and perhaps offering extra stomping opportunities between old/new publishing redirects.
I'm reluctant to edit PHP because
PHP is deprecated
re-gitified PHP content is liable to be stomped on
I do not understand the PHP
The hierarchical PHP does most of its work by inheritance from the modeling root so I see no 'main' program. Something exploits tables configured by derived classes. I have learned to tweak the tables, but have no idea how to prefix with a "if-project-XXX-then-redirect-to-PMI...". (I too once set up a PHP server, it was painful and is now long lost.)
Since PHP is going out of business I would expect the webmasters to
either set up override redirects at the file server/folder level
or create a higher priority index file that handles the JustJ/custom downloads projects before falling back to PHP. If necessary this is an example file that a committer can commit.
Since we are phasing out PHP, I am expecting a solution that supports the queries without using PHP at all.
You have quite a few expectations of what the webmasters ought to do, but unfortunately I don't think those are all realistic expectations; please don't shoot the messenger. It is possible,if not comfortable, for you to self serve via PHP though I think the path of least (and future proof) resistance is to redirect https://eclipse.dev/mmt/ to https://projects.eclipse.org/projects/modeling.mmt and update the portable to provide more end-user-friendly content.
As MMT co-lead, QVTd lead, QVTo releng/committer I have no recollection of any migration actually happening. (I don't think mdt/modisco has moved either.) Perhaps my fault becuase I'm still waiting for an explanation as to how ECAs will be able to edit the new 'wiki'.
I'm afraid that I do not understand the significance of projects.eclipse.org. I understand and trust www.eclipse.org, but domains such as .dev and .io make me very sick and untrusting. But if it helps the internal plumbing so be it. Is projects.eclipse.org a monolith like /cvsroot, if so how will committer-level
protection be managed with GIT supervising content? Or is projects.eclipse.org the next area to be undermined by the introduction of GIT?
In this issue, I'm interested in some proposal whereby https://www.eclipse.org/mmt/downloads/?project=qvtd redirects to the equivalent of the PMI download button without any use of PHP.
Beyond this issue, I'm interested in ensuring that the original /cvsroot/modeling/mmt/qvt/... continues to be accessible as http://www.eclipse.org/mmt/qvt/.... I'm not fussed about these repos moving to github just so long as it happens consistently and stomp-free. Oops, problem, I never used the project GITs so mmt/qvt contains material that is common to qvtd and qvto. Which project GIT do they move to? Maybe we have to have a distinct eclipse-qvt.
Your lack of understanding about https://projects.eclipse.org/ is something you'll need to address. The portal is a key resource for managing "metadata" about projects and is used for providing a common web interface for all projects. This is what you use nominate committers and to create release records, so you must have some familiarity already. It's basically a "database" for which there is a rest API, e.g.,
Each committer of each project can edit their project's details on the portal.
The URL https://eclipse.dev/ is water under the bridge, so rehashing that will accomplish nothing. Which domain suffixes you personally trust or find sickening is also beyond anyone's influence and is not the topic of this issue. Please focus.
The following comment you made is mean-spirited. It serves only to offend and to demonstrate your apparent desire to be disparage the folks who maintain Eclipse's web property:
Or is projects.eclipse.org the next area to be undermined by the introduction of GIT?
I have explained how the content on the web pages is mapped from the content of the git repositories. There is no reason to repeat the details.
As I've already mentioned (on another issue) you have two options (for any given project). Let me repeat them here:
You can have a website repository that you must manage yourself, including all content of all nested pages below your website root. Currently this is in PHP, is horrible to maintain, and will need to be rewritten. The webmasters will not create or modify pages for you and will not do any redirection of these pages; you can do that work yourself (if you can figure out how) and you as a committer are the only one who can do that (has commit access to do that).
You can use the the portal as your website; this is maintained via a web editor which is easy to use but not nearly as flexible as having your own website.
That's it. Each project has this choice. Please choose and move on. Do not spiral into orthogonal topics and do not disparage the Foundation staff. It is enough now.
(The webmasters gave themselves access to everything for security reasons. The existing facility appeared to be privided for me / imposeds on me by Nick Boldt, who I regarded as the EF, so IMHO the EF created and imposed all this deprecated PHP so the EF should be helping replace it.)
It is using the portal as a website that I do not understand.
I am well aware of editing metadata via the PMI; IMHO one of the EF's most helpful contributions.
However I am not aware of any ability to create webpages via the portal. If there is such a creation capability, then it seems reasonable that this should be GIT managed. Hence my concerns about policy evolution.
There is no ability in the portal to create pages, only the ability to create content for these tabs:
That's done by editing and filling out the content in the form:
Only committers can do that for any given project. There is no Git involved so no history. As I suggested, it's not flexible, and it's not powerful. It is but one of the choices available.
The more powerful git-hosted website is a lot more work to author and maintain. You might take inspiration from these:
My original question was about making an existing query work.
Clearly the portal has no ability to add support for a new query or even to add an arbitrary web page so I'm unclear why you suggest it.
I know nothing about web queries so I have no idea how to support such a query. I just ask the web team to explain how the query imposed on me for PHP can be supported post-PHP.
As I've explained, you make the query work by fixing the query engine, i.e., fixing PHP page. But you don't know how to do that or don't want to do that. Whatever the blockage here is, that's for you to deal with.
If you can't author what you want in the way you want it in the portal, i.e., option 2, then you will need a website, i.e., option 1.
Those are your choices 1 or 2. Choose 1, delete the entire Git repository and replace it with something not imposed on you. Learn to use Javascript to process queries to dynamically alter content.
The Foundation did not author the modeling websites. You may credit Nick Boldt with that. You may choose to regard him as EF though he was never employed by the Foundation.
The Foundation staff will not be authoring any project content for you nor for anyone, so don’t take that as a personal affront. You are empowered to fix your website content yourself now for immediate gratification.
In the long term, we hope to see guidance from the webdev team for best practices for authoring project websites.
I understand that there are a number of sources of frustration, but we are all in the same boat and will need to move forward. So please try to avoid circling back.
The webmasters asked for a simple query to escape from the long conversation of #3484 (closed)
@emerks Please stop subverting this with red herrings.
The EF created and imposed the downloads.php technology on modeling projects, so that we could tailor it to support our projects.
The EF is deprecating that technology so the EF should provide the replacement technology that we can tailor.
My query is whbat is that non-PHP technology. Maybe it is an index.html with embedded action language. Maybe it is redirections. I don't know, so I ask.
The title of your request as well as the initial details of your request are quite different from your final query/question above. This is the basis of my concern about focus and clarity.
I will need to overlook the characterization of explaining how the technology works and explaining your various options as subversive red herring content. I will also overlook your characterization of how the pile of PHP came into existence as well as who is responsible for that content today. This is the basis for my concern about lack of respect.
Yes we do hope to seem guidance on the path forward. That is the topic of the following issue and specifically there is already guidance offered here:
Repeating the request for guidance here is not so helpful. It's better that the guidance be in one place for everyone's benefit. So please read that note and ask for clarification there.
I think that means there is no other action to take for this issue...
Again: @emerks Please stop subverting this with red herrings.
Currently there is a problem with a stomped downloads.php. Therefore a request to bypass this is sensible. And the main way avoids using PHP or the problematic downloads.php that supports the queries that I ask the webmasters to suggest a replacement for.
Since the qvtd,qvt-oml,modisco and ocl projects have already updated the PMI, why not just use the PMI as the 'website' for those projects?
That puts the downloads link in front of users while leaving the projects in control, and means no need to ask for updates to 'static' redirects should they change in future.
The IT team does maintain www.eclipse.org/downloads/downloads.php , and projects are free to leverage it, but it's not meant to be a file 'browser' in any way, just a simple entry point to downloadable files while attempting to leverage our mirrors.
I was confused by the consideration of a 'website' and web editor. To me, a web site must support creation of a new page. The PMI could do quite a bit by squirreling things in documentation pigeon holes, but description of this as a website is really ambitious.
This issue requests support for the current spelling of legacy queries, not synonym replacemnts. I am not aware of any ability for the PMI to intercept the spellings I suggest. However I suspect that a redirect rule could do so, but I have no visibility on how the EF redirects.
Yes, I have updated the PMI so after entering https://www.eclipse.org/modeling/mdt/downloads?project=ocl I see the legacy OCL downloads page. If I now click GO to the OCL pull down, it no longer refreshes the page but goes presumably via the PMI to the wanted new page. I just want the query to go direct to the new page without editing the PHP, since a PHP solution will soon break.
@droy you confuse file authorship with intellectual authorship. The MMT files that I cloned were a tweak of M2M files after we were forced to vacate model-to-model to allow machine-to-machine to hijack the name. Of course machine-to-machine rapidly changed to IoT so I await getting M2M back again. Numerous low level names such as Java packages still use m2m.
Yes we have had a lot of good value out of this framework that came from none of us. That is why it is so upsetting that it is being trashed. Nick Boldt maintained some files for us and offered advice on tailoring. To me, Nick Boldt was the friendly face of the EF.
The blame game and the dredging of the river of history will accomplish nothing except to annoy the vey people from whom we need help and answers. Your frustration is clear, understandable, and has been expressed such that no further repeats are necessary.
is not what I see. As described in #4428 the URL initially goes to the PHP-created page. It is only after clicking Go! that the new page is reached.
are the result of some testing I did in order to try and resolve @ewillink s original 'problem statement' for this issue, hoping to get us all unstuck.
Please publish the redirects so that we can review and understand them rather than flounder around guessing at the magic.
Understand these redirects were created not by writing PHP, but by altering the web server configuration, so they aren't a great example of what projects may need to do.
Great. This looks like exactly the non-PHP technology I was asking for.
Details,
modisco should be https://download.eclipse.org/modeling/mdt/modisco/builds/release/latest/
If possible, it would be better to specify 'pressing the PMI download button' e.g (just guessing) https://projects.eclipse.org/projects/modeling.modisco/downloads?Downloadrather than hardwiring today's setting. The web server redirection would then track any change in the PMI.
Changing the web server config effectively 'hardwires' the redirection so it's not dynamic in any way. Which is why adding+maintaining these represents an ongoing cost for Webmaster and Project teams(we rely on you to tell us when things need to change). It's also specific to the site(eclipse.dev).
Which is why we encourage projects to use something like @emerks PHP suggestion(you can do equivalent things with raw HTML) as that leaves projects in the drivers seat.
Here's an HTML example for eclipse.dev/modeling/mdt/downloads/index.html
@mward Yes, return 301 https://download.eclipse.org/modeling/mdt/ocl/builds/release/latest/; is fragile, just waiting to be broken by the next phase of decontainerisation. This is why I suggested indirecting via the PMI, possibly by a syntax such as e.g (just guessing) https://projects.eclipse.org/projects/modeling.modisco/downloads?Download. Or, since https://projects.eclipse.org/projects/modeling.modisco/edit offers the Downloads URL property, perhaps there is a correct syntax for https://projects.eclipse.org/projects/modeling.modisco/downloads[Downloads URL].
If there is a syntax that clicks the Download button or navigates to the Downloads URL property, please use it. (If there isn't, there should be.). Failing that, linking to the PMI downloads page is next best. e.g.
return 301 https://projects.eclipse.org/projects/modeling.modisco/downloads;
As a result of those changes, modisco now has a download link:
It's also listed on the drop-down for this page:
Of course I (or anyone via a PR) can change those to redirect to the PMI or whatever else.
This demonstrates that we can do things ourselves directly in our own GitHub repository without the involvement of the webmasters, and it shows how we can do that.
The click-the-downloads-button-automatically is not a feature that the portal supports as far as I know; if or when that happens then we could use it until then we can point at the tab.
The modeling-website does not have an mmt folder so there is nothing to do.
With regard to mdt, as far as I can tell the following never contributes content to the website:
So in the interim we will use the redirections that we can control ourselves and in the future we will use new technology where we will also implement everything ourselves. We should rely as little as possible on the webmasters to provide specialized server configurations because that approach does not scale to hundreds of projects and creates confusion when the website is doing something other than what our own authored content indicates it should be doing.
So I think this issue can be closed because we have accomplished the goal on our own.
Ok, no click, but what about the "Downloads URL" lookup? The PMI Edit pages seem very like database configuration, so I would expect a 'get' capability.
No to closure. We require eclipse-mdt to dominate eclipse-modeling so that the 10 modifications since 2012 are re-instated. The edit of modeling/mdt in eclipse-modeling is fine as an experiment, but it is absolutely ilegal since the modeling/mdt content 'does not exist' and I suspect what was performed by a committer who lacks authiorisation to edit MDT. The content was moved to eclipse-mdt which is the only place where it should be edited, perhaps using a PR just like for eclipse-mmt.
No again to closure. We have not achieved our goal because we have not done so while obsoleting the use of PHP.
I supposed one could try to query the database, but there are all kinds of guards against cross site scripting so I don't know that eclipse.dev could read stuff from projects.eclipse.org and then use the data to create a link.
I must also say that the content of our webpages is unspeakably-horrible, outdated, and unprofessional. We would be much better off spending time on Hugo than to repair this steaming pile of refuse.
Let me be 100% clear with you @ewillink, I am done here. I have spent a great deal of time being reasonable in the face of directed personal attacks, I have addressed all the JustJ features you requested so that you can stop relying on the download PHP pages that no longer work well and will soon not work at all, I have investigated the modeling website structure in detail, I have gotten PHP working on my machine for the modeling sites that so I can actually test changes without simply pushing them onto the web, and I have used that to fix the content in order to provide the redirections requested in the first comment on this issue. I call that done.
You need only merge this change to get the remaining redirections that you asked for:
You may also create PRs to change the redirections URLs I've already provided for modeling/mdt.
You are empowered to do things yourself and I've demonstrated that I can and do help with that. So please act like the intelligible professional who I know you are.
Beyond that, you may choose to spin in circles, going on tangent after tangent, dredging up historical frustrations, asking others to do things for you, and so on, until we are all feeling dizzy and perhaps even nauseated. But I cannot continue to be part of that; the webmasters are my colleagues and I am here to help them as well as you. I am goal oriented and am focused on solutions. I have tried my best to demonstrate that I am here to help. But there does come the point in time when one must recognize futility and that point appears to be reached.
Well I'm done here too. I have better things to do with my life than try to make Eclipse right. Particularly when my comments art frequently ignored and the endless EF changes just provoke yet more rows. We still have eclipse-modeling stomping on eclipse-mdt. You struggle to make PHP work when we have a non-PHP solution. (Yes, thank you for your JustJ effort; sensible support of the first re-user. Off-PHP is now very possible.)
The recent 'GitLab runners' announcement sounds like yet another builds rework is in the offing.
The "Bugzilla will undergo maintenance 2024-03-29 18h00 CET. Bugzilla will be placed in read-only mode at that time." change does it for me.
When @droy can write "Apart from that, the search functionality in GitLab issues is completely useless and can not be trusted." why would one move from Bugzilla?
Bye bye. I'll continue as MoDisco committer. I stand down from MMT, OCL, QVTd, QVTo.
I'm sorry to hear that. We're all trying to make Eclipse better. We all feel that all too often other people don't really understand us or even listen to what we say. For me personally, I'm not sure there remains a single bit of infrastructure that I used for EMF 20 years ago that I can still use in the future; that has cost me a great deal of effort in the past and upcoming changes continue to cost me a great deal of effort going forward. So I can certainly understand your frustration because I share it. It just does little good to circle back on these frustrations and to vent them into every helpdesk exchange. What's done is done...
If you plan to step down as a committer on one or more projects---I would be sorry to see that---please inform the EMO and the Modeling PMC so that we can look for people to take up the slack. No matter what you decide, I am here to help.