Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Re: Build on the plan

Same. Indeed the overall build improvement that Jeff is thinking about seems to be in line with what I was describing earlier and the reorganization of the responsibilities between p2 and PDE Build.

Now, despite the apparent difference between the common build effort and the PDE Build changes evoked, I believe that the PDE Build changes foreseen could make it easier for the platform to leverage the common build infrastructure and not have to maintain its own set of scripts (or at least reduce it). Consequently I would be very happy to learn more about the common build at the workshop to be sure that we are not missing on collaboration opportunities.

Wrt to the dates, anytime before mid-November is good.


Inactive hide details for Jeff McAffer ---05/09/2008 04:33:28 AM---Yup, we are certainly aware of these efforts and it would beJeff McAffer ---05/09/2008 04:33:28 AM---Yup, we are certainly aware of these efforts and it would be great to have another workshop. My unde


Jeff McAffer <jeff@xxxxxxxxx>




05/09/2008 04:33 AM


Re: [eclipse-pmc] Re: Build on the plan

Yup, we are certainly aware of these efforts and it would be great to have another workshop. My understanding from the previous workshop intent (I was not able to attend), the current efforts are focused on simplifying the instantiation of a build system to build "add-on" bits (i.e., features and bundles that are added to existing Eclipse installs). Basically making it easier for project teams to get a build system up and running. This covers quite a few projects at Eclipse so is quite valuable. The challenge I mentioned in the original post is somewhat different.

In essence "build" is an overloaded term (my bad for using it in the original message). The system I was talking about is the combination of PDE Build and the Releng BaseBuilder where the latter is the set of scripts and other stuff that drives the former to create the Eclipse project builds. For all its foibles, PDE Build does quite a reasonable job of actually building (aka, compiling) bundles, fragments, features, ... The current setup handles innumerable special cases and quirky things that come with building the base part of Eclipse so we have to be careful to avoid biting off more than we can chew.

Historically we have not had a reasonable provisioning story so we overloaded PDE build and the BaseBuilder to do a lot of grovelling in the bytes, fetching, zipping, chmoding, transporting etc. With the advent of p2 we have the opportunity to improve the situation with modest effort *around* the core parts of PDE build by letting it do its thing and let p2 do the byte pushing/pulling/management. That opportunity was what I was trying to highlight in my original post.

Anyway, I just wanted to provide that clarification and state my support for having a build workshop. FWIW, the first week of Oct is not great for me. After that should be good.


Bjorn Freeman-Benson wrote:
      Eclipse PMC members,
      As you probably know from blog posts [
      1], bugs [2], and the wiki [3], there's a general community effort afoot, supported and abetted by the Foundation, to create a common build infrastructure across all Eclipse projects. It would seem appropriate (and the best use of limited resource) to have a common effort in this area, improving not only the Eclipse PMC's build systems but also the common build infrastructure (for all projects who want to use it)*.

      I'd like to propose a face-to-face kick-off of a unified effort. Early October? Ottawa? Build workshop number three with the specific goal of putting together a technology plan and a project plan. How about it?

      - Bjorn

          In the 3.4 round build was a big problem.  PDE build and the releng
          builder have evolved over time to handle many subtle and complicated
          usecases.  While it is great that it handles these, the infrastructure
          has evolved into an unmanageable, brittle and monolithic code mass.  
          Fundamentally it is inhibiting teams from making progress quickly and it
          is stressing the build and releng teams.  Further, as our consuming
          community grows and diversifies and things like e4 and Equinox blossom,
          the load on these teams and the technology will only grow.
      * note that "common" means available to all the projects if they want as opposed to "standard" as in "standard ip log" which means the projects must do it that way. In my vision, projects can still do their own builds in their own custom way if they want to.
      [end of message]

      eclipse-pmc mailing list

      eclipse-pmc mailing list

GIF image

GIF image

Back to the top