There have been a discussion about build naming conventions lately.  SNAPSHOTS, nightly, milestone, GA, maintenance, integration, stable, etc…

In both Nick’s and Mickael’s posts, I noticed a theme: all builds are the same. Of course when they are built, or the process by which the built artifacts are vetted may change, but the build process is the same for all build types: namely, take what’s in HEAD/Master/Trunk/Tip/Top/Main Branch, tag it and build it.

This isn’t the case for the Eclipse project. The Nightly builds are actually done differently from the integration, milestone, stable, and maintenance builds.

The build processes that Nick and Michael mentioned, assume that once something is in Master/Head, it’s ready to be released and the only other variable is release date.  The Eclipse process doesn’t assume this.  In fact, I can release a wad of changes the night before Juno ships and likely none of them will be in build.  This is because Eclipse requires explicit tagging of what you want built.

Here is how it works:

1. Development teams continually release stuff to master.  Each night master is built to ensure that nobody has introduced compile errors (or broke unit tests). This is not bleeding edge! This is not intended for anyone.  This is not similar to maven SNAPSHOTS.
2. When teams are happy with their work, they tag the bundle.
3. Integration builds happen weekly, and only what’s tagged will be built. Integration builds are similar to SNAPSHOTS, and can be consumed (if you want the most bleeding edge stuff).
4. This has recently changed, so instead of tagging each week, we merge (from master into ‘integration’). This means, what’s in master won’t necessarily be in a build each week.

I’m pretty sure I can hear the GitClub screaming feature branch, feature branch, feature branch. Why don’t you just use feature branches?

Please keep in mind:

1. Eclipse is over 10 years old, and predates Git.  Would you really do feature branches with CVS? (maybe)
2. The Eclipse build takes a while to complete:

• Let’s assume it takes 6 hours to build and run the tests (1/4 of a day).
• Let’s assume there are 10 teams (SWT, Debug, Workbench, PDE, JDT, UA, etc…)
• Let’s assume each team has 2 features on the go at all times: 20 feature branches
• Right now (for better or worse) a full Eclipse build, plus platform tests must run on the Eclipse build infrastructure
• So, if we had 20 feature branches that we had to build in sequence, it would take 5 days to build todays nightly
• Tomorrow’s nightly would start once that’s done!

Yes I realize some of those assumptions might be rather simplifying — maybe we could run the builds in parallel and off-load the costs to the hardware, but having a central build of 20 feature branches is still not feasible.  Also, some teams would likely want to combined builds (now build the SWT + Workbench feature branch together).

I know some people will head down the path of build restructuring (completely refactor the Eclipse build so developers can run them locally, thus removing the necessity for a centralized builds). We’ve heard this before many times.  Instead of suggesting this, sponsoring the effort (with money + people power) would be more helpful.  Also remember that Eclipse has successfully shipped on-time for the pat 10 years.  So, if you really want the team to change their process to the development flavour of the week, be prepared to show some evidence that process XYZ is better.

This was not meant to start a development war, but rather explain a bit about how the Eclipse build process works.  For better or worse, it’s what we have.

BTW, what do others do? Does everyone use feature branches and assume what’s in Master is ready? What did you do before Git (did you use branches for development in CVS/SVN)?

Happy Holiday’s Everyone!

As many of us start to get into the Holiday spirit, the Eclipse and Equinox teams have an early gift for you, Eclipse Juno Milestone 4.

Eclipse now supports Annotation based Null Analysis. (See Deepak and Ayushman’s posts for more information).

There are also enhancements to SWT (Tree Cursor)

And Equinox now supports Jetty 8 and Servlet 3.0

Checkout the  completely New and Noteworthy

or Download the Milestone and try it out yourself.

Eclipse Indigo is out and Eclipse Juno development is in full swing. That means it’s time to start thinking about the Eclipse release in 2013 (Only 18 months away). While development plans are still a far ways off, we’ve already started to collect ideas for the name.

Historically Eclipse has chosen names in Alphabetical order (Helios, Indigo, Juno), which brings us to the letter ‘K’. Since some alphabets don’t have the letter ‘C’, we could explore names like Kanada or Kookie Monster.

Of course, we can also go with villains from Star Trek like Klingon or Khan

I’m sure you’ll be much more creative than me.  If you’re interested in following this discussion, feel free to CC yourself on this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=365965

 

Does TDD actually improve software quality?  Are good software developers an order of magnitude better than poor ones?  Do multiple code reviews reduce the number of bugs in the software?  Does your choice of language improve productivity? Do distributed version control systems increase the number of contributions?

Many software developers (myself included) have strong beliefs about many of these questions.  In fact, order a round of beers at EclipseCon and bring up any one of these topics and see what happens. Unfortunately, many of us base our arguments on our own experiences or anecdotes.  Occasionally we will quote some self proclaimed expert in the field and assume our argument is ‘proven’.  Is this evidence?

As tool developers — building the Best Integrated Development Environment — we need to hold ourselves to higher standards. We cannot be designing future IDEs based solely on what works well for me. If you have a few minutes, please watch the following video by Greg Wilson on Software Carpentry: Software Engineering Empirical Results. http://software-carpentry.org/4_0/softeng/ebse. I had the good fortune of meeting Greg a few years ago through the Canadian Consortium for Software Engineering. A much longer version of the talk is available (embedded below): http://vimeo.com/9270320.

Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True from CUSEC on Vimeo.

I prefer the longer one as I think he makes a much stronger point about questioning beliefs.

This has been blogged about before by me and other guys, but as I still constantly experience this problem, a little repetition won’t hurt

In many projects you see the result of System.out.println() statements on the console: statements such as “here I am” or “this should not happen”. These are often left-overs from debugging sessions and flood the log. Although, I personally think there are almost no use cases where you would use sysouts over breakpoints or conditional breakpoints, you cannot just forbid the use of them. In fact, there are good use cases I know for sysouts, e.g. debugging drag and drop where you do not want the debugger to suspend on a drag over. However, polluting the code with sysouts should be a no go. A better solution is to put the sysout statement into the break point’s condition like this:

In this way you do not pollute the code and, if you want to persist your sysouts, you can export the breakpoints.

We had a great Democamp and birthday party in Munich. Thanks go to all the speakers, volunteers and attendees!

The evening started with a keynote by Ed Merks. He summarized 10 very interesting years. Some of the events he mentioned were already known, some were surprising, e.g. when Ian Bull started to use EMF in 2003

 

The second speaker, Kai Toedter showed a real working demo of how to use Java web start to start an Eclipse RCP application. To make it even more interesting, he started his demo application using the internet connection from Sven`s phone. You can download his slides here.

 

Manuel Bork presented the new Mylyn-GMF integration that allows the use of task focus on diagrams. This feature is also integrated into UML Lab.

Frank Appel showed how to create dynamic Web-Applications with RAP and OSGi. It was quite impressive to see him turning parts of a web application on and off using an OSGi console. At the end, he also demonstrated the same application running on an iPhone using the native RAP client for iOS. You can find his slides here.

Maximilian Koegel and me did a short “KINECT with Eclipse” demonstration.  If you’re not familiar with this demo, you can see more here.

Then we had a short break with beer and of course a birthday cake. It must have been good -  I wasn’t even able to take a picture of the whole cake:-)

After the break, Andre presented the tool, Ceno. It can help to avoid conflicts in projects by showing who is working on which class in real-time. You can download his slides here.

Tom Schindl presented his project “e(fx)clipse” Eclipse Tooling and Runtime for JavaFX. The styling options and the DSL to declarativly create the UI were especially great. You can find his slides here.

Ekke presented his first experiences with Eclipse PlugIns for BBX Native SDK. This enables the development of applications for the next generation platform for Blackberry smartphones and tablets.

Maximilian presented what’s new in EMFStore. He showed an example of a tool based on EMFStore and also showed an integration of EMFStore with the e4 workbench model. With this integration, the e4 model can be versioned between developers using EMFStore. The changes can even be pushed to a deployed application. As an example, one can switch off a certain feature for maintenance. See here for more information.

Sven Efftinge gave an introduction to Xtend and why it can and should be used daily. Xtend is a very thin layer above Java offering some innovations such as closures, which are not available in Java. Later, Sven also showed how to develop a very simple DSL with Xtext in 10 minutes. You can find more information here.

 

Ed presented Xcore, a textual syntax for Ecore created with Xtext. Xcore allows the definition of EMF models with the same ease as writing Java code. It also makes it very easy to embed Operations written in Java.

Thomas Schütz presented “Developing Embedded Systems with eTrice.” To me, the most interesting feature was that events on the target can be logged to create Message Sequence Charts(MSC) of the running application. You can find his slides here.

Thanks to all the speakers, the attendees and the volunteers for making this a great event and see you at the next democamp!

Eclipse has two annual conferences, EclipseCon (North America) and EclipseCon Europe. These are great venues to learn about what’s happening in the Eclipse eco-system, explore up-and-coming technologies and get to know the wonderful people behind Eclipse.

If you’re wondering how a ‘simple IDE‘ can fill two annual conferences, please read on!

EclipseCon Europe had a number of tracks, including talks related to modelling, Java 7, and Machine-to-Machine compatibility (yes, Eclipse has technology in all those spaces).  EclipseCon Europe also hosted the Eclipse 10th Birthday party!

I attended the conference.  Unfortunately, there were too many interesting talks and I missed many of the ones I really wanted to see.  Luckily the talks are now on-line at http://www.fosslc.org/drupal/category/event/ece2011 (if you can’t find your talk, wait a few days… they seem to be uploading them as I type this).  By having the talks available, I was able to attend the conference, meet with all the interesting people and still find time to absorb the technical details. This is a great service, thanks!

I should also point out that the deadline for talk submissions to EclipseCon (North America) is Friday November 18th.

Consider this:

 

I measured the time needed to create 200 Buttons in RAP 1.4 and RAP 1.5M3, and it shows a considerable performance boost (at least for the browsers i tested). One reason for this is that we changed from quirksmode to standard rendering in IE9, which among other things, finally allowes us to use its new HTML5-features (in this case SVG and CSS3). I expect another little boost with IE10, which has even more CSS3 support.

However, what i did not expect was a significant improvement in any other browser, in this case Google Chrome. This is likely due to the implementation of the JSON-based RAP-protocol. It remains to be seen how this develops, as work on the protocol is still going on. Currently eval() is used to parse the JSON. In the final release we will probably use other methods, such as the native JSON-parser present in many modern browser. Older browser may gain only little or no performance.

What is really awesome though is the improvment of the GC/SWT-Canvas performance in IE9 (and only IE9). Drawing in browser (without any plug-ins) used to be a real pain. While other browser adopted the HTML5-Canvas and SVG standard very early on, Microsoft stubbornly stuck to its horribly old VML implementation, making my work needlessly hard. One of the main problems with VML is that it gets exponentially slower the more elements you draw, from about 200 elements on it’s almost painful to watch. But this is 2011, HTML5 is all the buzz, and even MS could no longer ignore it. IE9 now has a decent HTML5-Canvas implementation that we use in RAP 1.5, and it shows:

The fine print:
These results were achieved on my Windows 7/64bit Intel i5 2,4 GHZ laptop. No other systems or browser were tested. Measurement was done using JavaScript. The 32bit version of IE9 was used. I did only 3 iterations each, but the deviance was relatively small. The results in the final RAP 1.5 release my be very different due to ongoing development. You can check out the code i used here.

Tags: canvas, CSS3, html5, IE9, Internet Explorer, rap

Eclipse sure has made a splash over the years. In celebration of the 10th anniversary of Eclipse, I pulled all the Eclipse splash screens from Git and put them all here (I skipped a few when there were only minor updates to the copyrights, etc…).

Trick or Treat!

Just in time for Halloween the Eclipse and Equinox teams have a treat for all you IDE enthusiasts… Eclipse Juno Milestone 3.  The transition to Git initially slowed some of us down, but the development teams have picked up speed now. There are lots of new things in M3 to test out.

OSGi now has a new console. It uses the Apache Felix Gogo project and supports tab completion, command history, piping, grep, and a whole host of other things.

Other new features include a global debug toolbar:

And Java resource leak detection

 

Checkout the entire New and Noteworthy, or better yet, download Juno Milestone 3 and try it yourself.