Data-driven Eclipse Project Landing Pages

A few months ago, I set about updating the look of the project summary pages that we automatically generate for projects. The code in the current project summary pages is, frankly, pretty brittle and I used the opportunity to do a little refactoring and add a little structure. I’m pretty happy with the changes: at very least, I’ve managed to significantly reduce the redundancy in this (and related) code.

But rather than just make another page that looks like the current project summary pages, I created something a little different. Instead of a project summary page, I’ve created something that I believe can be a reasonable stand-in for a project landing page.

At the moment, Eclipse projects are required maintain a project landing page using a combination of PHP and our “Phoenix” infrastructure. There’s a lot of useful functionality in Phoenix, but setting up the required infrastructure is a bit of pain. And it’s generally not a core-competency of a Eclipse project to be editing PHP.

The Data-driven Eclipse Project Landing Pages use the project metadata specified via the Eclipse Developer Portal, and renders in a very consistent manner. The generated page for the BPEL project, for example, looks as follows:

The Eclipse BPEL Project

A key difference between this page and the project summary page is that this page only displays information for which data has been provided: missing information isn’t displayed. I do try to do a little validation of the information, so–where possible–only information that actually makes sense is displayed. If, for example, a project specifies source code repository path that doesn’t point to a valid location, that path isn’t displayed (FWIW, I try really hard to make sense of the data in whatever form it is provided).

One of the things I’ve tried to add to this page is project navigation. The left “nav” area lists related projects (subprojects, siblings, parent, and top-level projects) and so provides a reasonable mechanism for navigating from project-to-project. I’ve been tinkering with some “previous project/next project” (using the inorder ordering of the project tree), but haven’t quite sorted out how to manifest this on the page.

Ultimately, this works best for projects that actually specify project metadata. The most challenging part–it seems–is providing a description. For reasons I am not privy to, the description is not actually stored in the project metadata; it’s stored in a file that is referenced via the descriptionurl metadata entry. Some projects just provide a pointer to their project’s landing page which–frankly–just makes a mess. I intend to spend a little energy in the coming weeks to identify these projects and help them fix it.

The code is quite stable, but is still very much a work-in progress. If you’re interested in using this as your project landing page, let me know and I’ll help you get set up. My hope is that–with your feedback and support–we can make this first class over the summer. FWIW, it’s actually possible to use elements from this page in your own pages (keep in mind that it’s a work-in-progress). Feel free to open bugs against Community/Portal for this functionality.

What do you think? Useful? Not useful?

This entry was posted in Community. Bookmark the permalink.

7 Responses to Data-driven Eclipse Project Landing Pages

  1. da152 says:

    Great work. I always thought that there is quite some redundant data at Eclipse and cleaning that up is good step forward.

    If I switch Eclipse Riena to have that as my project landing page, what are the steps and is there a temp area where I can try this feature before I commit to it ?

    thanks
    christian

    • waynebeaton says:

      Sorry… no temp area or staging server for website updates 😦

      Easiest way is to just change your project’s index.php to:

      This will change the URL in the browser.

      Do you want to preserve the URL? if so, then I’ll have to make “include” work, which may invalidate some of my assumptions…

  2. In the future, we could store most of the metadata if not all in the git repository itself. We would have keys for eclipse.project.name etc… this would just mean one less place to store stuff on foundation servers…

  3. kingargyle says:

    Or just store the information in the parent pom for the project.

Leave a comment