Many of us use IDEs, and most IDEs have some kind of build management process within them. However these files are always proprietary to the IDE and often fragile. Furthermore they need the IDE to work. It’s okay for IDE users set up their own project files and use them for individual development. However it’s essential to have a master build that is usable on a server and runnable from other scripts. So on a Java project we’re okay with having developers build in their IDE, but the master build uses Ant to ensure it can be run on the development server.Martin Fowler, Continuous Integration.
Sometimes when we are only focused on our portion of the universe it is difficult to image that there are other ways to do things. Eclipse hosted projects are in some ways unique. For the vast majority, they are all developing plugins that run on top of the IDE or as RCP applications. Which means they are going to be using Eclipse to develop things. However, step outside of the Eclipse microcosm, and things change dramatically. An example are the projects hosted at the Apache Foundation, GitHub, Sourceforge.net, and other places. Here there is a wide variety of ways people are contributing to open source projects. They are using Netbeans, IntelliJ, Vi, EMacs, XCode, etc. Each of the IDEs have their own build systems and their own way of building. Each of the IDEs provide their own spin on the build process. However, there appears to be some in the community that believe the IDE is the ideal way to build. That you should have to deploy the same set of plugins or IDE onto your build server to build your application. This works fine if you have a captured audience and everybody is going to use the exact same IDE, with the exact same configuration and plugins, however it starts to fall apart once you get outside.
The Master build that is the defacto standard needs to be IDE independent. Especially if you have a community that uses multiple ides. The build system really can be whatever you choose, but it should not be specific to a particular IDE. It just rubs me the wrong way. It is what bothers me about the concepts of Buckminster and B3 in general. If you are isolated to eclipse and eclipse plugins then there may not be a problem. But as soon as you step into the OSGI Runtime things start to change. It can cause more complications when you have to deal with a larger more disperse community. There you have people using systems like Bundle, PAX, Eclipse, and Tycho, and numerous other methods to create their bundles. Eclipse is just another player in that space.
Ideally, a build should be as easy as saying:
maven clean package
buildr clean test
Anybody should be able to run the build at any time with out necessarily having to have a specific IDE and specific version. The build should ideally be it’s own self testing entity.
So I’m all for modelling builds and making them easier to implement. But I’m more for making those models agnostic of the IDE. I still think it is a good thing that programmers SHOULD know how their software is built and deployed. But we do need to make it easier for those builds to be accomplished.