>Builds: We make them complicated – Follow Up

>So, my recent blog posting stirred some feathers, started some good discussions, and basically stimulated some creative brain cells. A couple of things that I noticed coming out of the discussion:

  • People tend to view the world through Eclipse as being the only OSGI development tool.
  • Many believe that a pure Java build system would be easier to deal with than any other build tool: i.e. ANT, Buildr, etc.
  • That PDE Build is so abstracted that it is very difficult to figure out what it is doing underneath.

I’ll try to address one point I see a problem with, and that is the way OSGI development is viewed and how the builds should be done. Currently, Eclipse is by far the best OSGI development, because like JDT before it for java development, it is built on top of OSGI. Developers need the tools to develop OSGI bundles. With that said, let’s not forget that their are other IDEs out there that can be used to construct OSGI bundles. Both IntelliJ and NetBeans both have plugins that allow OSGI bundles to be created, tested, and deployed.

So, this brings me around to a general point. Each of these IDEs probably goes about building a OSGI application a bit differently. The common thread was that as a programmer of OSGI bundles I want what I do in the IDE to be reproduced by the build. This may be different depending on the IDE you are using. This is a common item when dealing with traditional Java based development or Web Development. Different developers can use different IDEs. Each of these IDEs may produce their own flavor of how a build is to be done.

Because of these differences, and in many cases the build scripts generated by these IDEs being tied to functionality in the IDE, this is one of the reasons that Martin Fowler in Continuous Integration says a build should not depend on the IDE. Developers may and will use different IDEs when doing development. So the build script that does the build needs to be agnostic in this case.

As much as we like, eclipse for development, it isn’t the choice for everybody out there, and there are growing options for OSGI development outside of eclipse. Just something to keep in mind as the new build systems are constructed to replace and enhance the old.

This entry was posted in build, eclipse. Bookmark the permalink.

5 Responses to >Builds: We make them complicated – Follow Up

  1. >I don't think anyone envision a build system where you actually declare the semantics for the build in Java.Ant is pure java and the semantics are declared in XML. What some of us advocate is that instead the Ant XML (IMO, not ideal for declaring the build workflow), we should use a proper model, tailored for its specific purpose.Ant is like Emacs, or even Vi, in comparison with a real IDE. In all its simplicity, both Emacs and Vi are great. But in order to get really productive with development, you need something that can help you move up a few steps in the abstraction. So you pick an IDE. You don't stick with Emacs and Vi just because it's important not to be tied to the functionality in the IDE.The JDT team realized early that they needed a Java model to keep things alive in the IDE. Now the time has come to do the same with builds. I'm sure Ant will retain a lot of followers when it's ready. Just like Emacs and Vi still does.B3 (and Buckminster) is not limited to OSGi development. It's not tied to the Eclipse IDE. Nor is it targeted for just Java. Like P2, the objective is to provide a generic, extendable, and general purpose build tool.Not sure why you get so hung up on OSGi. It's just a modular framework. Just like ant is. The reason we want to use it is that it's far better then Ant in that respect.

  2. David Carver says:

    >@thomas Actually, their were several comments in the first blog entry where developers stated they wanted Java because that is what they are comfortable with and the tools they are familiar with. Not my words, it's theres.Personally, I don't care if it's OSGI or not osgi, it's just the opinion that since the Build works from my IDE that it should work the same in the build script. If you are solely working with eclipse, then great…but many open source projects need to deal with multiple IDEs so the build process needs to be agnostic in this case.Ultimately to me it doesn't matter if it's ANT, Maven, B3, Athena, Modeled, JAVA, Buildr, bash, XProc, or any numerous other scripting/pipeline languages, as long as the developers as a group take responsibility for the build and how it works. The way we develop and how we integrate with others is still the biggest point of build failures in my opinion.

  3. >You say "since the Build works from my IDE that it should work the same in the build script."I couldn't agree more. I have one Build. It works, both in the IDE and outside the IDE. The exact same code executes in both cases.You have two Builds, one inside the IDE and one outside. And the justification for the redundancy is the possibility of a third Build in some other IDE?Wouldn't it be simpler to take my one build and adapt that to the other IDE as well? That's one of the advantages using a real model. It can be adapted to different environments.

  4. David Carver says:

    >@thomas Eclipse projects are unique in many ways because Eclipse is used by 99% to develop the bundles.If you step outside the eclipse world, into other open source projects, you have devs using a wide variety of ides, or just plain text editors. Thus there needs to be one build that runs with out an IDE influence. In many cases, what happens is that the IDE specific builds, are not the Normative builds, it's the one outside that isn't IDE specific.Modeling can help, but aren't we just introducing another tool into the situation? Won't we end up inventing yet another DSL for the builds based off the model?

  5. >When designing B3 (and Buckminster too for that matter), we do indeed target the world both inside and outside of Eclipse.One of the primary objectives for Buckminster was that you should be able to run it as a headless build tool, in any environment, without the IDE. Just like Ant. One of the first projects that we targeted was a traditional Make system where 90% of the code was written in C. A majority of the users did not use Eclipse.With B3, we want a model. So we need the tooling for that. Eclipse provides state of the art tooling. EMF is extremely well layered which means that the runtime needed to use the model is very small. We just can't get things like that for free in any other domain. Ant doesn't provide us with anything that comes close. So we use EMF. But that does not mean that the build systems created with it can be used only in the Eclipse world. It just means that in that world, you get very good tooling to support your build model.Regarding creating another DSL, we might use Xtext to make it really easy to do plain text editing of the model. It's certainly an option. We have not found any DSL's today that are rich enough to describe a build.If you're interested in the B3 model, and what a future DSL might look like, then please join the discussion our our IRC (eclipse-b3) or our Eclipse newsgroup eclipse.b3.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s