Twitter github

A Common Build Infrastructure for Eclipse?

I want to share with everyone an important EclipseCon Short Talk which I think needs some attention. From my experience, one of the biggest hurdles an Eclipse project (or Eclipse-based product) faces is setting up a good build infrastructure. What I mean by good build infrastructure is automated builds and good reporting that leads to easy diagnosis of problems. A prime example of good build infrastructure comes from the EMF team.

Nick Boldt (EMF) has developed a system where it is really easy to kick-off and disseminate information from builds. Particularly, the EMF project has two components which make it really easy to tell what’s going on with the project. First, there is the Release Notes component which associates bug numbers with releases (through clever committing and analyzation of CVS log files). The SearchCVS component allows you to search for commits easily.

What are people’s thoughts about the talk (vote!) or even a possible BOF at EclipseCon (or even an Eclipse project proposal around this idea!). It’s my opinion that all Eclipse-based projects could benefit from a unified build infrastructure (plus, it will get my colleagues to stop throwing profanities my way about handling build with Eclipse).

  • AlBlue

    A BoF at EclipseCon sounds like a good idea. I’ve been saying much the same thing for a while, but never got around to doing anything about it. And that might then precipitate a project on Eclipse subsequently.

  • AlBlue

    A BoF at EclipseCon sounds like a good idea. I’ve been saying much the same thing for a while, but never got around to doing anything about it. And that might then precipitate a project on Eclipse subsequently.

  • Le ScaL

    In the fall last year such an event has been organized. It was called “build workshop” and it took place in Portland. Like in any of those events everybody said that they will do something but in the end not much happened (at least not that I have seen).

    To me the problem with such a common build project/infrastructure is that everyone wants to use it but noone wants to have to maintain / pay for it.

  • Le ScaL

    In the fall last year such an event has been organized. It was called “build workshop” and it took place in Portland. Like in any of those events everybody said that they will do something but in the end not much happened (at least not that I have seen).To me the problem with such a common build project/infrastructure is that everyone wants to use it but noone wants to have to maintain / pay for it.

  • Bob Balfe

    That is correct about no one ever wanting to pay for it. Another aspect is automated and integrated build verification testing. Once a successful build has completed an automated BVT suite should be kicked off and results also posted with the release binaries. This way anyone who wants to pick that build up knows the problems with it.

  • Bob Balfe

    That is correct about no one ever wanting to pay for it. Another aspect is automated and integrated build verification testing. Once a successful build has completed an automated BVT suite should be kicked off and results also posted with the release binaries. This way anyone who wants to pick that build up knows the problems with it.

  • Nick

    Agreed, it’s hard to get support for maintenance, but that’s one of the goals of automation & abstraction: doing more with less, without having to know the inner workings.

    I disagree that not much happened in the Build Summit meeting in September: true, not ALL the goals tabled have been completed, but some good work did happen, and still more is ongoing. Beyond that, awareness was raised and common practises were discussed, which has prompted more cross-project collaboration and cooperation, IMHO.

    Regarding build verification, I’ll be sure to include this in my talk, or in any BoFs that spring up thereafter. Currently, my BVT involves a fairly complex set of checks, the results of which are simply displayed iconically on our various downloads pages.

    Other projects do things differently, such as WTP, which reports simply what PDE spits out.

  • Nick

    Agreed, it’s hard to get support for maintenance, but that’s one of the goals of automation & abstraction: doing more with less, without having to know the inner workings. I disagree that not much happened in the Build Summit meeting in September: true, not ALL the goals tabled have been completed, but some good work did happen, and still more is ongoing. Beyond that, awareness was raised and common practises were discussed, which has prompted more cross-project collaboration and cooperation, IMHO. Regarding build verification, I’ll be sure to include this in my talk, or in any BoFs that spring up thereafter. Currently, my BVT involves a fairly complex set of checks, the results of which are simply displayed iconically on our various downloads pages. Other projects do things differently, such as WTP, which reports simply what PDE spits out.