Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #215301 +++ The standard URL for getting a HTML rendered version of an XML project plan is, taking the dsdp.tm project as example: http://www.eclipse.org/projects/project-plan.php?projectid=dsdp.tm The problem with this approach is, that it always uses the "current" project plan as specified in the project metadata for the "current" release stream. Now the project metadata also requires adding a "project plan" field with each completed release. Taking current TM 3.0 release as example, I'd like to associate a HTML rendered version of the TM 3.0 project plan XML with that release, but that doesn't seem to be possible right now. Or am I expected to associate the naked XML with that field?
Transferring to Phoenix.
As deadlines are approaching where projects are *required* to produce their project plans in XML, it is getting more and more urgent that we need a facility to render *any* project plan XML properly. See bug 215301 comment 73 for reference. I'm increasing severity since I cannot see how (at least some) projects or components can present their required XML plans in a consumable way (PHP, HTML) right now, so this is a blocker for our process.
(In reply to comment #2) > As deadlines are approaching where projects are *required* to produce their > project plans in XML, it is getting more and more urgent that we need a > facility to render *any* project plan XML properly. See bug 215301 comment 73 > for reference. > > I'm increasing severity since I cannot see how (at least some) projects or > components can present their required XML plans in a consumable way (PHP, HTML) > right now, so this is a blocker for our process. > I agree... I need to get some time set aside to update the XML Schema to the current version of the spec. In the future I would like to see that the schema be the driver so that they don't get out of synch. Also, I heard some mention of an xslt, does one exist for rendering the XML? if so I could take a look at enhancing it if it isn't in synch with the current xml.
(In reply to comment #2) > I'm increasing severity since I cannot see how (at least some) projects or > components can present their required XML plans in a consumable way (PHP, HTML) > right now, so this is a blocker for our process. While I understand that the current PHP page and meta-data only renders the most current project plan, I don't see how you jump from that to saying that "projects cannot present their plans in a consumable way"? You certainly can represent the current project plan in the xml format and it (I think) all works. Is there some bug I'm missing vis a vis current project plans? (Note that components are not first-class entities yet and thus do not have separate project plans.) (In reply to comment #3) > In the future I would like to see that the schema > be the driver so that they don't get out of synch. > Also, I heard some mention of an xslt, does one exist for rendering the XML? All the code is in CVS: /cvsroot/org.eclipse/www/projects/project-plan.php I'm happy to accept patches to fix bugs or add new and wonderful features.
Created attachment 109655 [details] Patch adding a "&planURL=" parameter Attached patch (against /www/projects project) makes the enhancement, by adding a "&planURL=..." parameter to the PHP script. I committed a clone of the project-plan.php script to try it out: http://www.eclipse.org/dsdp/tm/development/project-plan.php?projectid=dsdp.tm&planURL=http://www.eclipse.org/dsdp/tm/development/tm_plan_3_0.xml The URLs that the planURL parameter accepts are limited to URLs from "http://www.eclipse.org" only in order to avoid getting rogue stuff into the system. Because the "&projectId=" argument is also required, even more strict restrictions could be made e.g. only allowing exchange of the final name component of the planURL compared to the plan that's specified by the project in the Portal, but this is not currently done.
PS another, probably safer, approach to fit my needs would be accepting an argument "releaseid" in order to specify for which release the plan should be generated. But I don't understand the PHP $project structure enough in order to understand how a "releaseid" argument could be used to select the correct projectplanurl from the correct release entry in the database.
(In reply to comment #6) > PS another, probably safer, approach to fit my needs would be accepting an > argument "releaseid" in order to specify for which release the plan should be > generated. > > But I don't understand the PHP $project structure enough in order to understand > how a "releaseid" argument could be used to select the correct projectplanurl > from the correct release entry in the database. > Part of the problem in getting this done is the way the XML is currently setup. We might want to look at this for next years version of the plan. Mainly what needs to happen is the following: <plan plan-format="1.0" xmlns="http://www.eclipse.org/project/plan" xmlns:html="http://www.w3.org/1999/xhtml" name="Project Name"> <release projectid="technology.dash" version="1.0" <introduction> <html:div>Some xhtml content here. Make sure to use the prefix before the elements</html:div> </introduction> <release_deliverables> <html:div>Some xhtml content here. Make sure to use the prefix before the elements</html:div> </release_deliverables> <release_milestones> <preamble> <html:div>Some xhtml content here. Make sure to use the prefix before the elements</html:div> </preamble> <milestone date="7/1/2008" milestone="M1"><html:div>optional html</html:div></milestone> <milestone date="8/1/2008" milestone="M2"><html:div>optional html</html:div></milestone> <milestone date="9/1/2008" milestone="RC1"><html:div>optional html</html:div></milestone> <milestone date="6/28/2009" milestone="1.0"/> . . . </release> All the content need to move to be underneath the release element, and then there can be multiple release elements that identify the version and project id. Then the XSLT can easily only display the information that is related to that particular version and project id.
Hm, my thoughts have always been around having a separate XML file for each release, and have the PHP select the right one. I think that the first thing that needs to happen, is change the foundation (portal) database such that each release has its own plan (perhaps that happened already, I'm not sure). Then, the PHP can select either the latest release's XML file or a previous release's one. I don't think that the XML needs to change for this.
(In reply to comment #8) > Hm, my thoughts have always been around having a separate XML file for each > release, and have the PHP select the right one. > > I think that the first thing that needs to happen, is change the foundation > (portal) database such that each release has its own plan (perhaps that > happened already, I'm not sure). > > Then, the PHP can select either the latest release's XML file or a previous > release's one. I don't think that the XML needs to change for this. > that would work as well, and easier for me. :) No XSLT changes.
Bug 261724 comment 6 has another use-case why this feature is needed: in order to distribute plan modifications for review (in rendered form) before actually committing them, the project plan renderer needs to be capable to render specified XML files. When I'm not mistaken, security (i.e. rogue XML leading the renderer to hog the web server) was one concern why the project plan renderer doesn't allow arbitrary paths for the XML. One proposed solution for that was that additional slots for multiple different plan versions should be available in the Portal database. Another option could be if the Portal specifies root directories or patterns that are considered "safe" for plan XML, and the renderer allows any files below those root directories or patterns. What's the current status of this? Do we have slots for multiple release / plan versions already? When could we get the renderer to render different plan versions?
Now that we are starting planning for our second release using the standard plan format (Helios), this has become quite important. For documentation purposes, we need a stable URL for our Galileo plan, even after our "current" plan has been updated to be the Helios plan. We have the metadata for plan URLs corresponding to each release, now we just need the project-plan.php script to be updated. Has anyone looked at Martin's patch? I'm wondering in this bug has been lost because it is still assigned to portal inbox but is in the Website component.
One thing that can be done is to use the XSLT to generate a HTML version of the current Galileo plans. This would then in essence freeze a copy of the Galileo Plan, and it can be used an archive. This can be easily done using the XSLT ant task to create the hard static copies.
>One thing that can be done is to use the XSLT to generate a HTML version of the >current Galileo plans. This would then in essence freeze a copy of the >Galileo Plan, and it can be used an archive. This is what I've had to resort to, but I have to say the rendering isn't pretty. For example the text is touching the left side of the window with no margins (using Firefox 3.0.5). If any XSL hackers out there have ideas on improving this, let me know: http://eclipse.org/eclipse/development/eclipse_project_plan_3_5.xml
(In reply to comment #13) > >One thing that can be done is to use the XSLT to generate a HTML version of the > >current Galileo plans. This would then in essence freeze a copy of the > >Galileo Plan, and it can be used an archive. > > This is what I've had to resort to, but I have to say the rendering isn't > pretty. For example the text is touching the left side of the window with no > margins (using Firefox 3.0.5). If any XSL hackers out there have ideas on > improving this, let me know: > > http://eclipse.org/eclipse/development/eclipse_project_plan_3_5.xml > You can use a CSS for the HTML that is generated. That is what the current project plan php render does. It takes the HTML produced and styles it with CSS.
This issue is becoming an issue for the BIRT team. We would like to publish our plan for the Fall Maintenance release now, and I am assuming this should be using the XML format (previously we have used a Wiki page). Until we have support for multiple releases in the XML infructure, we are stuck. I agree that we should have a seperate XML file for each release. It would be too cumbersome to have multiple releases in one XML file. The workaround of taking "snapshot" of the rendered XML file into some other document and then updating the XML with the new plan does not seem like a workable approach. Problem is that any links to the old plan from, for example, the Galileo pages would now point to the wrong plan. For the BIRT project, we keep an accurate history of all release plans so that these are available to the community if needed. So we have: <earlier releases omitted for brevity> BIRT 2.3 BIRT 2.3.1 BIRT 2.3.2 BIRT 2.5 etc. Net is that we would like to be able to have an XML plan for any number of releases, and to be able to point the renderer to the appropriate plan as needed.
You can do this already today. Just link to the individual plans like this: http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/dash/athena/project-info/plan.xml&component=Athena eg., http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/birt/project-info/plan-birt232.xml&component=BIRT+2.3.2
Sigh, it looks like Martin's patch from comment #5 was accepted, but nobody bothered updating this bug report. Thanks Nick! This works for me...
This should work for BIRT as well. We'll try it out. Thanks!
