tag:blogger.com,1999:blog-175473942024-03-12T23:26:29.994-05:00Boris BokowskiTravelling across CanadaBoris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.comBlogger47125tag:blogger.com,1999:blog-17547394.post-14284311650995839802011-07-07T17:27:00.000-05:002011-07-07T17:27:28.178-05:00Moving to GermanyAfter six years in Ottawa, working for IBM, I have decided to move back to Germany with my family. Today was my last day in the office, and on Saturday we will be embarking on a longer vacation, driving from Ottawa all the way to Vancouver, before we board our one-way flight to Germany.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-cR6mEN7-AYE/ThYxHHHW8lI/AAAAAAACLQ4/-6p55GxN1Z0/s1600/IMG_0365.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="266" src="http://2.bp.blogspot.com/-cR6mEN7-AYE/ThYxHHHW8lI/AAAAAAACLQ4/-6p55GxN1Z0/s400/IMG_0365.PNG" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">We'll try to pass by Orion, AB :-)</td></tr>
</tbody></table>I may be able to remain an Eclipse committer, but it will definitely no longer be my main job. I decided to join Google at their Munich office at the end of the summer, and expect to be working on web-based tools there.<br />
<br />
Over the last year or so, I spent most of my time getting the Orion project off the ground, which is about web-based tools and how tools from various servers can work together. We are code complete for our first tech preview release, which will be announced in a few days. The goal for this first release was to get to the point where we can self-host, and the team will from now on use Orion itself to develop Orion. I've been doing this for the last few weeks already, and it's a lot of fun to never leave the browser, from filing a bug, fixing and testing it, committing and pushing the fix, and closing the bug. There is a lot of potential for Orion, and I will be closely watching its progress.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-CYPIuR6C_Zs/ThYxpg2WYDI/AAAAAAACLRY/5HEYZ_ZwxCg/s1600/IMG_0405.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="298" src="http://2.bp.blogspot.com/-CYPIuR6C_Zs/ThYxpg2WYDI/AAAAAAACLRY/5HEYZ_ZwxCg/s400/IMG_0405.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">I will also try this chocolate (thank you, Steve!)</td></tr>
</tbody></table>It's been a blast. I've been very fortunate to work with some of the smartest people in the industry, both here at IBM as well as in the Eclipse community. I have learned so much. Thank you!Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com23tag:blogger.com,1999:blog-17547394.post-49446104407370466952011-03-08T16:07:00.001-05:002011-03-08T16:09:17.084-05:00Don't forget to vote!<div dir="ltr" style="text-align: left;" trbidi="on">If you are an Eclipse committer, please take a few minutes of your scarce time to vote in the <a href="http://www.eclipse.org/org/elections/nominees.php">Eclipse Board elections</a>. There are only three days left, voting ends on Friday March 11th at 3pm Eastern time! <br />
<br />
If you are an individual (not employed by a member company) committer: Please click <a href="http://www.eclipse.org/membership/become_a_member/membershipProcess.php">here</a>, and sign and send the membership agreement to the Eclipse Foundation. This will enable you to vote in the upcoming board member elections. There is no cost, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.<br />
<br />
Why should you do that? Let me try to explain with a diagram:<br />
<br />
<div style="text-align: center;"><img src="http://www.diagrammr.com/png?key=dbNyxCvIHtt" /><br />
<div style="text-align: center;"><span style="font-family: arial; font-size: 78%;">(thanks, <a href="http://www.diagrammr.com/">diagrammr</a>!)</span></div></div><br />
Here is the same information in text form, copied from the <a href="http://www.eclipse.org/org/elections/election_process.php">election process</a> web page:<br />
<ul style="font-style: italic;"><li>Each Committer Member gets one vote. Note that committers who are employees of Member companies have all the rights and privileges (including voting) of a Committer Member. </li>
</ul><ul style="font-style: italic;"><li>Individual committers must join the Eclipse Foundation as Committer Members by signing the <a href="http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20AGMT%202008_04_16%20Final.pdf">Membership Agreement</a> in order to be allowed to vote. </li>
</ul><ul style="font-style: italic;"><li>All committers who are employees of a single company have their votes collapsed into a single vote in the committer elections.</li>
</ul>That's right: every vote from an individual committer member (someone who signed the individual membership agreement) is worth exactly the same as the votes from all EclipseSource committers combined, or all Oracle committers combined, or all itemis committers combined, ... you get the idea.<br />
<br />
That seems <a href="http://ed-merks.blogspot.com/2008/02/one-committer-one-vote.html">a little bit weird</a>, but it sort of makes sense considering the situation back when the rules were made: IBM had way more Eclipse committers than everybody else, and there was a risk that they would determine the committer representatives, who then could be seen as voting in favour of IBM - leading to an imbalance at the board of directors. So when you think about it, the rules ensure that the committer representatives election is truly independent of any potential company interests.<br />
<br />
So, to repeat, if you are an individual (not employed by a member company) committer: Please click <a href="http://www.eclipse.org/membership/become_a_member/membershipProcess.php">here</a>, and sign and send the membership agreement to the Eclipse Foundation. It's free (of charge), it will enable you to vote in the upcoming board member elections, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.<br />
<br />
More votes mean more weight for the committer representatives on the Eclipse Board of Directors. And if you are an individual committer, your vote weighs a lot.<br />
<br />
Thank you! </div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com1tag:blogger.com,1999:blog-17547394.post-1492891820099125132011-02-01T23:22:00.001-05:002011-02-02T02:04:57.758-05:00New features in Orion M5<div dir="ltr" style="text-align: left;" trbidi="on"><br />
We shipped a new milestone of <a href="http://wiki.eclipse.org/Orion">Orion</a> yesterday. For those who haven't heard about Orion yet, its goal is to build developer tooling that works in the browser, at web scale. The idea is to exploit internet design principles throughout, instead of trying to bring existing desktop IDE concepts to the browser.<br />
<br />
There are two new features in this new milestone (<a href="http://download.eclipse.org/e4/orion/drops/S-0.2M5-201101311515/index.html">download</a>) that I would like to highlight:<br />
<ul style="text-align: left;"><li>the ability to install, as a user, editor actions supplied by third-party web sites, and</li>
<li>a very early integration with Firebug.</li>
</ul><span class="Apple-style-span" style="font-size: large;">Editor Actions</span><br />
<br />
In any decent editor, you'd want the ability to customize - adding new key bindings, new functionality, and changing its look. We have a first implementation that covers the first two of these, with an interesting twist: Editor actions can come from anywhere on the Internet!<br />
<br />
Here is our favourite example, code formatting functionality for JavaScript files: Have a look at <a href="http://jsbeautifier.org/">http://jsbeautifier.org</a>, which hosts a JavaScript formatter that is implemented in JavaScript, and has been developed independently of Orion. It was astonishingly easy to add a little bit of glue code around it to make it available as a command in the Orion editor. Thanks to <a href="http://spicausis.lv/">Einar Lielmanis</a>, the author of this JavaScript code formatter, the resulting code is even hosted at jsbeautifier.org!<br />
<br />
To make the command available in your local installation of Orion, you would go to <a href="http://localhost:8080/view-registry.html">http://localhost:8080/view-registry.html</a>, which is a special page showing your installed plugins. Enter <a href="http://jsbeautifier.org/orion/jsbeautify.html">http://jsbeautifier.org/orion/jsbeautify.html</a> in the text box and click on Install. The new plug-in should now be listed in the tree. Now navigate back to the Orion code editor, or hit reload on an existing Orion code editor in another tab, and enjoy the new action available in your editor's toolbar. You can read more about this in <a href="http://eclipsr.blogspot.com/2011/02/orion-m5-and-plugins.html">Simon's blog</a> - he implemented a lot of the frameworky stuff to make this possible.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/_9mAUrmH9eMo/TUjV9xk25MI/AAAAAAAB-gk/gEvXL61-9cM/s1600/Screen+shot+2011-02-01+at+22.53.45+.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/_9mAUrmH9eMo/TUjV9xk25MI/AAAAAAAB-gk/gEvXL61-9cM/s1600/Screen+shot+2011-02-01+at+22.53.45+.png" /></a></div><br />
<br />
This is a humble start of being able to pull functionality from all over the web into your development environment, which itself is web-based. Note that the server wasn't involved at all!<br />
<br />
One of the next steps will be to add this extensibility to our navigator as well, and to expand what's possible from an editor action. Currently, editor actions see the selected text, the complete editor buffer, and the start and end of the current selection. They can change just the selection, or the complete buffer and the current selection. With just this minimal API, there is already a lot you can do - implement traditional editor actions, but also navigate within the editor buffer, change the contents of the entire buffer, or even contact a server for more heavy-duty processing.<br />
<br />
If you have interesting ideas for what you could do with this, contact me (on <a href="http://twitter.com/bokowski">Twitter</a>, the #eclipse-orion channel on <a href="http://wiki.eclipse.org/IRC">IRC</a>, or the <a href="https://dev.eclipse.org/mailman/listinfo/orion-dev">Orion development mailing list</a>) and I'll give you an account on our demo server at <a href="http://orion.eclipse.org/">http://orion.eclipse.org</a> - we are slowly adding users there - so far it's by invitation only.<br />
<br />
<span class="Apple-style-span" style="font-size: large;">Firebug Integration</span><br />
<br />
If you are doing web development, <a href="http://getfirebug.com/">Firebug</a> is one of the indispensable tools these days. It does much more than the usual code debugger: yes, it lets you set breakpoints, single-step, and inspect variables visible from your stack, but it also supports monitoring HTTPS requests, inspecting the browser's DOM, looking at CSS styles, and more.<br />
<br />
So instead of implementing some kind of debugger inside of Orion, it would be much better to integrate with existing debuggers that already exist. The question of course is, what does it mean to integrate? We have two main "integration points" in mind: being able to open the Orion editor on a file you see in Firebug, and synchronizing breakpoints between Firebug and Orion.<br />
<br />
So far, we've worked on the first one only, as a start. It involved a little bit of code on the Orion side, and a little bit of code on the Firebug side. Thanks a lot to John J. Barton, the Firebug lead, for working with us on this! To try it out, you need to install a Firebug 1.7 alpha version as well as a Firebug extension called Dyne. The detailed instructions are <a href="http://getfirebug.com/wiki/index.php/Editing#Orion_Web_Editor">on the Firebug wiki</a>. Once installed, you should be able to open <a href="http://orion.eclipse.org/file/org.eclipse.orion.client.core/static/view-registry.html">http://orion.eclipse.org/file/org.eclipse.orion.client.core/static/view-registry.html</a> while Firebug is active. Open the script panel, you will see a new button "Edit". Clicking on this button opens the Orion code editor in a new browser tab.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/_9mAUrmH9eMo/TUjY3ftKdpI/AAAAAAAB-go/CFIELcIEJdk/s1600/Screen+shot+2011-02-01+at+23.03.16+.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="340" src="http://3.bp.blogspot.com/_9mAUrmH9eMo/TUjY3ftKdpI/AAAAAAAB-go/CFIELcIEJdk/s640/Screen+shot+2011-02-01+at+23.03.16+.png" width="640" /></a></div><br />
<br />
Clearly, there is still ways to go before this flows nicely, but it's a great start. What I like in particular is that this is all based on an extra header Orion is sending, from which Firebug can construct the URL which contains the editor. This means that any web-editable resource could be edited in this way, just by adding custom headers - there is nothing Orion-specific that had to be put into the Firebug code base!<br />
<br />
<span class="Apple-style-span" style="font-size: large;">Looking Ahead</span><br />
<br />
Both of these features illustrate the direction we want to take with Orion, and they align perfectly with our <a href="http://wiki.eclipse.org/Orion/Development_principles">development principles</a>. I'll quote two of them here:<br />
<blockquote><b><i>Reuse existing technologies</i></b><i> - Don't re-invent the wheel if one already exists that we can integrate (through HTTP, or as open source that we consume), even if we could build a better wheel ourselves.</i></blockquote><blockquote><b><i>Low barrier of entry for adopters</i></b><i> - We don't want to force people to have to re-write code just so that it fits into Orion, nor do we want them to have to re-write just so they can use one of our components.</i></blockquote>Looking ahead, here is our list of ideas for additional integrations with existing web-based services:<br />
<ul style="text-align: left;"><li>Paste selected text to <a href="http://pastebin.com/">pastebin.com</a>.</li>
<li>Create a new <a href="https://gist.github.com/">Gist</a> from the current editor buffer.</li>
<li>In the navigator, add an action to <a href="http://shmush.it/">smush</a> (remove unnecessary bytes from) an image.</li>
<li>Multi-select a few files and click on an action to generate a <a href="http://lmgtfy.com/?q=css+sprite">CSS sprite</a>.</li>
<li>Upload the current editor buffer to <a href="http://codepad.org/">codepad</a>, and insert the result from running the code at the bottom of the editor buffer.</li>
<li>Send files to the <a href="http://validator.w3.org/">W3C validator</a>.</li>
<li>Look up a word in a thesaurus and display alternative names.</li>
</ul>I'd love to hear your suggestions. What should we add to the list? What should we work on first? Would you be interested to work with us on a similar integration? You can contact me on <a href="http://twitter.com/bokowski">Twitter</a>, the #eclipse-orion channel on <a href="http://wiki.eclipse.org/IRC">IRC</a>, or the <a href="https://dev.eclipse.org/mailman/listinfo/orion-dev">Orion development mailing list</a>.</div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com0tag:blogger.com,1999:blog-17547394.post-51719502165487597512011-01-11T11:25:00.000-05:002011-01-11T11:25:13.780-05:00OrionToday, the Eclipse project is embarking on a journey towards web-based development tooling. We don't have too much to show except some initial code written by members of the original Eclipse team from IBM (including myself), a new name "Orion", and a gleam in our eyes.<br />
<br />
The initial code is meant to be a seed. What we have today is a fast and scalable code editor that runs in all major browsers, plus some code around it for navigating files and folders, and doing full-text search. This is a humble start, something to kick things off. Longer term, our vision is to enable integration between all kinds of open web-based tools. Have a look at our <a href="http://wiki.eclipse.org/Orion">wiki pages</a> if you want to learn more about Orion.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/_9mAUrmH9eMo/TSxxqhag7uI/AAAAAAAB-Fo/vxjbwV13gYk/s1600/orion-screenshot.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="430" src="http://2.bp.blogspot.com/_9mAUrmH9eMo/TSxxqhag7uI/AAAAAAAB-Fo/vxjbwV13gYk/s640/orion-screenshot.png" width="640" /></a></div><br />
<br />
But wait... "Why would I want to run an IDE in a browser?"<br />
<br />
You probably wouldn't. IDEs are big honking applications that take a while to load, use up all your computer's resources, and come loaded with features that you don't even know existed. Believe me, I helped build one of them. Although the Platform is not to blame really, it's the hundreds of plugins that use up all the resources ;-). Anyway, you wouldn't want to jam all that into a single web page or browser tab.<br />
<br />
What you <i>would</i> do is use a web browser to access functionality that is important to you as a software developer. Chances are you're already doing this today! For example:<br />
<ul><li>using a web-based bug tracking system like Bugzilla</li>
<li>monitoring your build using a web-based tool like Hudson</li>
<li>reviewing code changes using a tool like Gerrit</li>
<li>reading documentation and searching for code snippets using a browser</li>
<li>browsing other people's code repositories using services like GitHub.</li>
</ul>So all we are suggesting is that you move the remaining software development activities to the browser, too. Long term. Very long term if you want. Those who get a lot of value out of the current desktop based IDEs should probably continue to use them for a while, or forever. In the case of Eclipse, the past ten years have seen a tremendous amount of investment in tools that run as plugins in Eclipse, and I wouldn't recommend throwing all that out of the window.<br />
<br />
But if you don't get a lot of value, for example if you are doing client-side web development, all you need in addition to the above browser-based tools is:<br />
<ul><li>a decent code editor,</li>
<li>a way to navigate your files and folders,</li>
<li>a way to version-control your files,</li>
<li>and a debugger.</li>
</ul><br />
This is exactly what we're trying to build first. We have a code editor and a way to navigate files and folders, we started working on a Git integration, and for the debugger we plan to integrate well with Firebug.<br />
<br />
For this to make sense as a way to develop software, you'd want all those browser-based tools to work together. Ideally, you'd want something similar to the tight integration you typically get from a classic IDE, but without building another IDE. We want to build something that works well with <i>existing</i> tools out there on the web, and we cannot ask others to buy into a new programming model that we may come up with. Therefore, our approach has to be based on well-proven web architectures - using hyperlinks to navigate between different tools and resources, making data accessible in a RESTful way, and using web technologies like HTTP, JSON, OAuth, OpenID, and others.<br />
<br />
Over the next few weeks and months, we hope to sign up others who would like to work with us on the <a href="http://wiki.eclipse.org/Orion/Project_mission_statement">vision</a>, the <a href="http://wiki.eclipse.org/Orion/Development_principles">development principles</a>, the <a href="http://wiki.eclipse.org/Orion/Architecture">architecture</a>, and <a href="http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/">the</a> <a href="http://git.eclipse.org/c/e4/org.eclipse.orion.client.git/">code</a>. The intent is to start a new project at eclipse.org soon - see also <a href="http://dev.eclipse.org/blogs/mike/2011/01/11/introducing-orion/">Mike Milinkovich's blog post</a> on Orion for more information on the project creation aspect. Until then, the code is going to be developed in the <a href="http://www.eclipse.org/e4/">e4 incubator</a> project, which is pretty open to contributions from anyone. If you are interested in participating, let me know.<br />
<br />
If you've read this far, you might just be the person we've been waiting for. Read our <a href="http://wiki.eclipse.org/Orion">wiki pages</a>, <a href="http://download.eclipse.org/e4/orion/">download the code</a> and try it out, or join us on <a href="http://wiki.eclipse.org/IRC">IRC</a>, we're using #eclipse-orion on irc.freenode.net.Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com15tag:blogger.com,1999:blog-17547394.post-30388213698235252912010-07-28T14:47:00.001-05:002010-07-28T14:47:56.712-05:00Eclipse 4.0 Overview<div class="separator" style="clear: both; text-align: center;"></div><div style="text-align: left;">Since I don't have enough energy left to also write a <a href="http://dev.eclipse.org/blogs/mcqjustmcq/2010/07/28/growing-the-future/">thousand words</a>, here is just an overview picture of the <a href="http://www.eclipse.org/eclipse4/">Eclipse SDK 4.0</a> Early Adopter Release that we shipped today. I hope you find it useful.</div><a href="http://1.bp.blogspot.com/_9mAUrmH9eMo/TFCHFfsxl2I/AAAAAAAByiU/NsmzXkR80uc/s1600/Eclipse+4+Architecture.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="516" src="http://1.bp.blogspot.com/_9mAUrmH9eMo/TFCHFfsxl2I/AAAAAAAByiU/NsmzXkR80uc/s640/Eclipse+4+Architecture.png" width="640" /></a>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com1tag:blogger.com,1999:blog-17547394.post-91961776801338991772010-07-12T10:09:00.006-05:002010-07-12T10:35:39.648-05:00Reminder to submit proposals to ESE 2010<div style="text-align: left;">The submission system for Eclipse Summit Europe has been open for a while now, and the deadline is approaching. Now that the Helios release train has successfully shipped<sup>1</sup>, it is time to think about talks or tutorials that you want to submit.</div><div><br /></div><div><div style="text-align: center;"><img style="cursor:pointer; cursor:hand;width: 236px; height: 90px;" src="http://3.bp.blogspot.com/_9mAUrmH9eMo/TDszEE11WUI/AAAAAAABxw0/KlYSEC_JpuU/s400/Screen+shot+2010-07-12+at+11.21.17+.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5493040315620481346" /></div><div><br /></div><div style="text-align: left;">The main topics for ESE 2010 will be Embedded, Modeling, Runtime, and e4. If you have something to say or teach about these subjects, then great. But don't be discouraged if you have a proposal that doesn't quite fit in these categories. Make a submission anyway.</div><div><br /></div><div style="text-align: center;"><a href="http://www.eclipsecon.org/summiteurope2010/submissions/?page=submissions"><img src="http://3.bp.blogspot.com/_9mAUrmH9eMo/TDszXYAYsgI/AAAAAAABxw8/PUPQD681lg8/s400/Screen+shot+2010-07-12+at+11.22.48+.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5493040647182529026" style="cursor: pointer; width: 178px; height: 39px; " /></a></div></div><div style="text-align: left;"><br /></div><div style="text-align: left;">Eclipse Summit Europe is a great conference, at a really nice location. To make it a success, we need quality content from the Eclipse community, in other words: from you!</div><div style="text-align: left;"><br /></div><div style="text-align: left;"><sup>1</sup> What a weird image, a train that is shipping. <a href="http://upload.wikimedia.org/wikipedia/commons/7/7e/Trajekt_im_Strom.jpg">It's been done before</a>, though :-)</div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com0tag:blogger.com,1999:blog-17547394.post-65336741542260527542010-03-13T19:10:00.003-05:002010-03-13T19:54:01.573-05:00Announcing the e4-Rover Mars ChallengeFor the last couple of weeks, a few people from the e4 team and NASA JPL have been busy working on a <a href="http://www.eclipse.org/community/e4RoverMars/challenge.php">cool programming contest</a> to introduce e4 to the EclipseCon attendees, and to encourage them to try out e4 and learn about it. (See below for acknowledgments.)<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.eclipse.org/community/e4RoverMars/rover.png"><img style="cursor: pointer; width: 300px; height: 123px;" src="http://www.eclipse.org/community/e4RoverMars/rover.png" alt="" border="0" /></a><br /></div><br />The idea is to drive a LEGO rover to collect points - <a href="http://www.eclipse.org/community/e4RoverMars/howtoplay.php">your mission</a> is to align the robot's on-board "instruments" with martian "rocks" in an arena. There are two ways to win - collect the most points to win a Lego Mindstorms NXT 2.0 set, or write the best e4-based client to win a Lego Mindstorms <span style="font-style: italic;">and</span> a trip to the NASA robotics lab in Los Angeles. Other prizes include credits for Amazon Web Services and T-Shirts.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.eclipse.org/community/e4RoverMars/nasa.png"><img style="cursor: pointer; width: 150px; height: 128px;" src="http://www.eclipse.org/community/e4RoverMars/nasa.png" alt="" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.eclipse.org/community/e4RoverMars/mindstorm.png"><img style="cursor: pointer; width: 150px; height: 23px;" src="http://www.eclipse.org/community/e4RoverMars/mindstorm.png" alt="" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://www.eclipse.org/community/e4RoverMars/amazon.png"><img style="cursor: pointer; width: 150px; height: 61px;" src="http://www.eclipse.org/community/e4RoverMars/amazon.png" alt="" border="0" /></a><br /></div><br />The architecture of the game system is interesting - the Lego robot executes commands that are sent to it from a local machine via bluetooth. The clients won't communicate with this local machine directly though - to make everything scalable, data about the state of the game, and an overhead view of the arena and the rover is made available using Amazon Web Services. We have an Equinox-based server on EC2, and are using S3 for making data available in a scalable way.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_9mAUrmH9eMo/S5wnxrWDf2I/AAAAAAAADQw/CKk-YJ00ihM/s1600-h/e4rover.png"><img style="cursor: pointer; width: 400px; height: 327px;" src="http://4.bp.blogspot.com/_9mAUrmH9eMo/S5wnxrWDf2I/AAAAAAAADQw/CKk-YJ00ihM/s400/e4rover.png" alt="" id="BLOGGER_PHOTO_ID_5448273383613759330" border="0" /></a><br /></div><br />We provide a <a href="http://www.eclipse.org/community/e4RoverMars/getstarted.php">basic e4-based client</a>, with a joystick-like way to control the rover. If you want to win the grand prize, you'll have to improve the client to make it look better and operate the robot more efficiently. We basically want people to hack the client to beat the game. To help you do this, we have started a <a href="http://docs.google.com/View?id=ddtx7p76_81t8kngxd2">tutorial</a> (which we'll refine and expand over the next few days) and a <a href="http://docs.google.com/View?id=dcxsfdff_25dp9b5wgf">FAQ</a>. We will also add some more comments to the client code, and perhaps tweak the code a little bit, so make sure you check if there are newer versions of the source code available.<br /><br />To give people a head start we are making the current source code for the client available today. You can download the code now, run the client but you can't actually control the robot. You need a hash key to control the robot and those will only be given out at EclipseCon. What you will be able to do is watch us have some fun playing with the robot, erm, I mean, perform more testing, because the client includes a webcam view of the robot. More detailed instructions are available on the <a href="http://www.eclipse.org/community/e4RoverMars/challenge.php">contest web pages</a>.<br /><br />I have been playing with the robot for the last week. For a little while, I was at the top of the high score list, but since then others have gotten much better. I'll have to end the blog post here to do some more testing. ;-)<br /><br />Driving the rover is a lot of fun! It's only a week or so until you can play too, at <a href="http://www.eclipsecon.org/2010/">EclipseCon</a>.<br /><br />P.S. Credit for the idea goes to Jeff Norris, who will be presenting a keynote on Wednesday. Khawaja, Victor, and Mark from Jeff's team worked on the hardware and the server side, and Brian de Alwis, Benjamin Cabe and myself wrote the simple e4 based client. Lars Vogel is helping with the documentation. Ian Skerrett from the Eclipse Foundation is coordinating everything, Lynn is going to help run the contest at EclipseCon, and a good number of e4 committers have been recruited as volunteers.Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com0tag:blogger.com,1999:blog-17547394.post-24475161258367284412010-02-23T15:15:00.003-05:002010-02-23T15:55:37.299-05:00Eclipse Board Election Facts (2010 edition)<div style="text-align: center;"><a href="https://foundation.eclipse.org/vote2010/"><img src="http://www.eclipse.org/membership/vote2008/vote.jpg" /></a><br /></div><div><br /></div>You have hopefully seen one of the <a href="http://www.eclipse.org/community/newsletter/2010/2010February.html">announcements</a> that the elections for <a href="http://www.eclipse.org/org/elections/nominees.php">committer representatives</a> for the Eclipse Board of Directors is now open.<div><br /><div>Rather than explaining why you should vote for me :-), I thought it would be useful to summarize the key election facts:</div><div><ul><li>You are voting for a one-year term starting April 2010. Voting is open as of yesterday, for three weeks until March 12, 3 pm Eastern time. Check out the <a href="http://www.eclipse.org/org/elections/nominees.php">committer candidates</a> and their vision statements.</li><li>To vote, check if you received an email from emo@eclipse.org on Feb 19, 2009. It contains the <a href="https://foundation.eclipse.org/vote2010/">URL</a> for voting, as well as the required voting password. If you haven't received a voting password, you are probably not (yet) an Eclipse member, and have to sign the membership agreement first<span class="Apple-style-span" style=""></span>. To understand why this is required, read <a href="http://www.eclipse.org/membership/become_a_member/committer.php">this page</a>, then read <a href="http://www.eclipse.org/membership/become_a_member/membershipProcess.php">this page</a> to make sure you fill out <a href="http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20AGMT%202008_04_16%20Final.pdf">the form</a> correctly. No voting privileges without signing the form!</li><li>The Board will have 20 directors, as follows:<ul><li>Fourteen directors for the <a href="http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic">strategic members</a>, one seat per member.</li><li>Three directors from "<a href="http://www.eclipse.org/membership/vote2008/">sustaining members</a>". There are six candidates on which sustaining members (companies) get to vote.</li><li>Three directors representing the committers. There are five <a href="http://www.eclipse.org/org/elections/nominees.php">committer candidates</a>.<br /></li></ul></li></ul></div></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com1tag:blogger.com,1999:blog-17547394.post-87502658806635988482010-02-08T10:12:00.006-05:002010-02-08T13:14:48.935-05:00SuffrageAt the risk of playing with words whose connotations I don't fully understand... Eclipse committers have to suffer - a little bit - to be enfranchised. I mean, to get the right to vote in the <a href="http://www.eclipse.org/org/elections/nominees.php">2010 Eclipse board member elections</a>, which begin two weeks from today, on February 22, 2010.<br /><br />If you are an individual (not employed by a member company) committer: Please click <a href="http://www.eclipse.org/membership/become_a_member/membershipProcess.php">here</a>, and sign and send the membership agreement to the Eclipse Foundation. This will enable you to vote in the upcoming board member elections. There is no cost, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.<br /><br />Why should you do that? Let me try to explain with a diagram:<br /><br /><div style="text-align: center;"><img src="http://www.diagrammr.com/png?key=dbNyxCvIHtt" /><br /><div style="text-align: center;"><span style=";font-family:arial;font-size:78%;" >(thanks, <a href="http://www.diagrammr.com/">diagrammr</a>!)</span><br /></div></div><br />Here is the same information in text form, copied from the <a href="http://www.eclipse.org/org/elections/election_process.php">election process</a> web page:<br /><ul style="font-style: italic;"><li>Each Committer Member gets one vote. Note that committers who are employees of Member companies have all the rights and privileges (including voting) of a Committer Member. </li></ul><ul style="font-style: italic;"><li>Individual committers must join the Eclipse Foundation as Committer Members by signing the <a href="http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20AGMT%202005_06_16%20Final.pdf">Membership Agreement</a> in order to be allowed to vote. </li></ul><ul style="font-style: italic;"><li>All committers who are employees of a single company have their votes collapsed into a single vote in the committer elections.</li></ul>That's right: every vote from an individual committer member (someone who signed the individual membership agreement) is worth exactly the same as the votes from all EclipseSource committers combined, or all Oracle committers combined, or all itemis committers combined, ... you get the idea.<br /><br />That seems <a href="http://ed-merks.blogspot.com/2008/02/one-committer-one-vote.html">a little bit weird</a>, but it sort of makes sense considering the situation back when the rules were made: IBM had way more Eclipse committers than everybody else, and there was a risk that they would determine the committer representatives, who then could be seen as voting in favour of IBM - leading to an imbalance at the board of directors. So when you think about it, the rules ensure that the committer representatives election is truly independent of any potential company interests.<br /><br />So, to repeat, if you are an individual (not employed by a member company) committer: Please click <a href="http://www.eclipse.org/membership/become_a_member/membershipProcess.php">here</a>, and sign and send the membership agreement to the Eclipse Foundation. It's free (of charge), it will enable you to vote in the upcoming board member elections, and as an added bonus, the Eclipse Foundation is now sending really nice thank-you e-mails to those individual committers who become members.<br /><br />More votes mean more weight for the committer representatives on the Eclipse Board of Directors. And if you are an individual committer, your vote weighs a lot!<br /><br />Word definitions.<br /><blockquote><span style="font-weight: bold; font-style: italic;"><a href="http://en.wikipedia.org/wiki/Suffrage">Suffrage</a> </span><span style="font-style: italic;">(from the Latin suffragium, meaning "voting tablet", and figuratively "right to vote", and originally a term for the pastern bone used to cast votes) is the civil right to vote, or the exercise of that right.<br />...<br />Where </span><a style="font-style: italic;" href="http://en.wikipedia.org/wiki/Universal_suffrage">Universal suffrage</a><span style="font-style: italic;"> exists, the right to vote is not restricted by race, gender, belief, wealth or social status. It typically does not extend a right to vote to all residents of a region; distinctions are frequently made in regard to citizenship, age, and occasionally mental capacity or criminal convictions.</span><br /></blockquote><br /><div style="text-align: left;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_9mAUrmH9eMo/S3BPnWpMZBI/AAAAAAAADOc/59ZSXHHC2c0/s1600-h/enfranchise.gif"><blockquote><img style="cursor: pointer; width: 400px; height: 130px;" src="http://4.bp.blogspot.com/_9mAUrmH9eMo/S3BPnWpMZBI/AAAAAAAADOc/59ZSXHHC2c0/s400/enfranchise.gif" alt="" id="BLOGGER_PHOTO_ID_5435932287748039698" border="0" /></blockquote></a><br /></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com4tag:blogger.com,1999:blog-17547394.post-76271423788458880472010-02-04T22:48:00.005-05:002010-02-04T23:52:49.462-05:00Can we turn e4 into an orange?Let me write a quick response to Elias' <a href="http://eclipsesource.com/blogs/2010/02/05/is-e4-a-lemon/">thought-provoking post</a>. I hope there will be other (and not so quick) responses as well - it is important to step back every now and then to assess whether we are going in the right direction. But for now, I didn't want to let the issues he raises without an answer from the e4 team. The question for me is, how can we turn e4 into a juicy and sweet lemon? ;-)<div><br /></div><div><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_9mAUrmH9eMo/S2uiol0IjhI/AAAAAAAADOU/VGPq0TbcKJU/s1600-h/orange-e4.jpg"><img src="http://4.bp.blogspot.com/_9mAUrmH9eMo/S2uiol0IjhI/AAAAAAAADOU/VGPq0TbcKJU/s400/orange-e4.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5434616193581878802" style="cursor: pointer; width: 400px; height: 350px; " /></a></div><div><br /><div><b>Killer feature: </b>I fully agree that support for styling and skinning is not going to be enough of a killer feature to convince everybody that it is worth stepping up to e4. What could be other killer features? To be honest, I am not sure. I would be interested in hearing opinions on this - please leave comments!<br /><b><br /></b></div><div><b>Download size: </b>The 230 MB are easy to explain - this download includes the 3.x Eclipse SDK (167 MB), the EMF SDK (27 MB), some parts of WTP, GEF, and other bits and pieces. If you just look at the e4 bundles, they amount to just over 2 MB. The dependencies of the core e4 bundles (a subset of those 2 MB) are SWT, JFace, Equinox, and the EMF core runtime. It could always be smaller, but the 230 MB are just the wrong number to look at. Unless you are interested in the footprint of e4 + compatibility layer + everything from the current Eclipse SDK, but clearly it is not the long-term goal of e4 to always ship with everything from 3.x.<br /><br /></div><div><b>Different: </b>This takes a little longer to explain, but luckily a good response already existed, in the form of John Arthorne's argumentation from <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=300099#c4">bug 300099 comment 4</a> (I made minor adjustments to make it fit better into this blog post):</div><div><br /><div><i>The purpose of injection was to make it easier to obtain services in the general case, as well as to decouple of service user from knowing or caring about who provided the service. I'll offer a couple of examples that I've taken from the existing 3.x code (all from the current ResourceNavigator.java in 3.6):<br /></i><br /><i>1) I want to print a message on the status line. In 3.x this is:</i><br /><br /><tt> getViewSite().getActionBars().getStatusLineManager().setMessage(msg);</tt><br /><br /><i>In e4 this should be:</i><br /><br /><tt> @Inject<br />IStatusLineManager statusLine;<br />...<br />statusLine.setMessage(msg);</tt><br /><br /><i>2) I want to get the selected resources:</i><pre> ArrayList list = new ArrayList();<br />if (selection instanceof IStructuredSelection) {<br /> IStructuredSelection ssel = (IStructuredSelection) selection;<br /> for (Iterator i = ssel.iterator(); i.hasNext();) {<br /> Object o = i.next();<br /> IResource resource = null;<br /> if (o instanceof IResource) {<br /> resource = (IResource) o;<br /> } else {<br /> if (o instanceof IAdaptable) {<br /> resource = (IResource) ((IAdaptable) o)<br /> .getAdapter(IResource.class);<br /> }<br /> }<br /> if (resource != null) {<br /> list.add(resource);<br /> }<br /> }<br />}<br />return new StructuredSelection(list);<br /></pre><i>I'm not sure how we handle multi-selection in e4, but this should be something<br />like:</i><br /><pre> @Inject<br />public void setSelection(@Named("selection") List<IResource> selection) {<br />selectedResources = selection;<br />}</pre><i>3) I want to associate a help context with my control</i><span class="Apple-style-span" style="font-family:monospace;font-size:100%;"><span class="Apple-style-span" style=" white-space: pre;font-size:13px;"><span class="Apple-style-span" style="font-family:Georgia, serif;font-size:130%;"><span class="Apple-style-span" style=" white-space: normal;font-size:16px;"><br /></span></span></span></span><pre> getSite().getWorkbenchWindow().getWorkbench().getHelpSystem().setHelp(<br /> viewer.getControl(), getHelpContextId());<br /></pre><i>In e4 this should be something like:</i><br /><br /><tt> @Inject<br />IWorkbenchHelpSystem helpSystem;<br />...<br />helpSystem.setHelp(viewer.getControl(), getHelpContextId());</tt><br /><br /><i>The end result is simpler code, but it also removes a mass of assumptions that<br />the client previously had to make, about what their containment structure<br />looked like and where specific services came from. I think we sometimes take<br />for granted how difficult it can be for clients in 3.x to figure out where to<br />get particular service from.</i><br /><br /><i>Having said all that, we have probably gone too far down the<br />"non-specification" route in e4. I think it is essential that we provide<br />interfaces containing specification of things clients must implement (e.g., you<br />need a doSave() method for parts that are to be used as editors). We can make<br />the interface optional if we want, but there has to be somewhere where we<br />specify the behavior expected/required for clients. To me this specification of<br />expected behavior for clients is orthogonal to service injection so I hope that<br />we can have both.</i></div></div></div></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com14tag:blogger.com,1999:blog-17547394.post-81428839740229382432010-02-03T21:43:00.003-05:002010-02-03T22:54:08.217-05:00Sometimes, bug triage is no funHere is how I intend to respond to a private email that I received today, about a bug that was filed yesterday. How would you respond in a similar situation?<br /><br />Hi [X],<br /><br />Thank you for reporting a problem with Eclipse. But - and maybe it's just me - the private email you sent today comes across as demanding. You are asking us to help you quickly, without investing time on your side to make the problem easy to reproduce for us. I understand that it's frustrating when things don't work the way you think they should work. However, remember that Eclipse is free software, and please consider if you are not already getting a lot more than your money's worth.<br /><br />So, in your own best interest, could you please use Bugzilla (that way, everybody interested in the issue can follow the discussion), and help us reproduce the problem with as little time investment as possible on our side? I have already asked twice, on the bug, but I will ask one more time: Please attach [a file that will allow us to reproduce the issue] to the bug. I would expect to be able to use [list of steps] to get the source code into my Eclipse. Before uploading the attachment, it wouldn't hurt if you tried the import operation on a fresh workspace to confirm that we will be able to just run it. By the way, the recommended way to produce the file to attach would be [list of steps].<br /><br />Thanks,<br />BorisBoris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com12tag:blogger.com,1999:blog-17547394.post-31765888724077506972010-01-18T15:29:00.004-05:002010-01-18T16:43:44.751-05:00Eclipse LabsMike <a href="http://dev.eclipse.org/blogs/mike/2009/12/07/project-community-enhancements-for-2010/">wrote on his blog</a> back in December that the Eclipse Foundation is "looking at creating an Eclipse Foundation affiliated forge where projects which are based on the Eclipse platform, but are not interested in hosting at eclipse.org can run their projects."<br /><br /><div style="text-align: center;"><a href="http://trubyte.dentsply.com/pro/eclipse_labs.shtml"><img src="http://trubyte.dentsply.com/pro/images/ELD_Button.jpg" /></a><br />Click on the image, but it's not an official eclipse.org Eclipse Lab!<br /></div><br /><br />Admittedly, this announcement was a little vague, most probably because this is part of the Eclipse Foundation's program plan for 2010, and lots of details still need to be worked out. In the comment section, Mike wrote that he is "expecting to announce this at EclipseCon in March." This tells me that there are at least a few open questions that need to be answered, or negotiations that need to take place, or else this could have been announced in detail already.<br /><br />As a committer representative on the Eclipse Board of Directors, I know a little bit more (but not too much) about this, but Board meetings are confidential, for good reasons - otherwise Mike wouldn't be able to openly discuss his vision and plans with the Board, which is one of the main functions of the Board of Directors.<br /><br />So let me just go through what everyone does know (or can know) so far, based on what Mike has written in his blog posting and in the corresponding comment section, with a little bit of added interpretation and speculation just because it's <a href="http://gizmodo.com/5434566/the-exhaustive-guide-to-apple-tablet-rumors?skyline=true&s=i">rumour season</a>:<br /><br /><ol><li>"An Eclipse Foundation affiliated forge where projects ... can [be] run" sounds to me like a concrete place for project hosting, i.e. a URL like eclipselabs.org. It turns out that this domain has been registered in December by the Eclipse Foundation. My hope is that soon, eclipselabs.org can be listed in the "Specific requirements" section of <a href="http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities">this wikipedia article on software hosting facilities</a>, as a specialized software forge for Eclipse-related open source projects.<br /><br /></li><li>This is for projects that "are not interested in hosting at eclipse.org", and "Eclipse Labs will hopefully over time form a powerful complement to the projects hosted at Eclipse.": Sounds to me like existing projects at eclipse.org will not be affected. Instead, I hope, this will be attractive by pulling together open source projects that currently would have to be started or hosted elsewhere (e.g. at Sourceforge, Github, Google Code, ...).<br /><br /></li><li>"There will obviously be some constraints (e.g. only Eclipse Foundation projects can use the org.eclipse namespace, and be part of the release train)": Sounds like there will be a clear distinction between Eclipse projects on one side and Eclipse Labs projects on the other side. There are many good reasons why you may want to run a project at a less restrictive software forge, for example:<ul><li>minimal overhead to get started</li><li>use whatever process you like for releases, adding and removing committers, adding dependencies to other software, etc</li><li>no mandatory IP review</li></ul>Likewise, there are many good reasons why projects find it attractive to be Eclipse projects hosted at eclipse.org:<ul><li>benefit from the Eclipse brand and Eclipse marketing efforts</li><li>use the same meritocratic principles and practices as every other project, making it easy to build trust across projects</li><li>approved IP cleanliness, to ease adoption by large organizations and governments</li></ul></li></ol>So while the <a href="http://eclipse-projects.blogspot.com/2010/01/foundation-as-service.html">"Foundation as a Service" idea</a> is an interesting thought experiment, I think a reasonable next step is to create Eclipse Labs as a place to start Eclipse-related open source projects easily. This will establish two Eclipse-branded places for hosting projects, at opposite sides of the fast-and-loose vs. regular-and-dependable spectrum.<br /><br /><div style="text-align: center;"><a href="http://www.eclipselaboratories.com/About.htm"><img src="http://www.eclipselaboratories.com/Images/ABOUT_topimage.gif" /></a><br />Yet another non-eclipse.org Lab, click on the image!<br /></div><br /><br />Eventually, it will become important to handle the transition between Eclipse Labs and eclipse.org. For example, a project at Eclipse Labs may want to move to eclipse.org at a later point in time when it is more mature. Anything that can be done to ease this transition will be to the benefit of Eclipse, and it may make sense that projects make the transition in several steps. For example, an Eclipse project may want to depend on software from an Eclipse Labs project, at which point an IP review will have to be conducted on the eclipse.org side. Or a project at Eclipse Labs may want to become an incubating eclipse.org project, which would mean adopting the Eclipse processes but not necessarily a full IP review until the project makes a release at eclipse.org.<br /><br />I hope this was useful information^H^H^H^H^H^H^H speculation. ;-)<br /><br />P.S. I have used some words of <a href="http://milesparker.blogspot.com/2009/11/jumping-into-deep-end.html">Miles Parker's excellent blog post</a> for the reasons why you would choose Eclipse Labs vs. eclipse.org as the place to run an open source project.Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com5tag:blogger.com,1999:blog-17547394.post-3533368199603490892009-11-30T17:30:00.002-05:002009-11-30T17:39:01.940-05:00Step Up or Shut UpSo we're at it again, sigh...<br /><br />It seems that the same people are commiserating the tragedy of the commons at Eclipse, at regular intervals, over and over again. Complaining is not a very good way to get what you want - I know one thing or the other about this as a father of three ;-). Complaining may work once or twice, but if you keep repeating the behaviour, people will stop listening to you.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_9mAUrmH9eMo/SxRFQtrJNPI/AAAAAAAAC8c/KEygAt__ot8/s1600/241745451_328400b1c0_o.jpg"><img style="cursor: pointer; width: 359px; height: 400px;" src="http://2.bp.blogspot.com/_9mAUrmH9eMo/SxRFQtrJNPI/AAAAAAAAC8c/KEygAt__ot8/s400/241745451_328400b1c0_o.jpg" alt="" id="BLOGGER_PHOTO_ID_5410025205819585778" border="0" /></a><br /></div><br />Normally, I would just sit these things out but this time I feel compelled to add some oil to the fire:<br /><ul><li><span style="font-weight: bold;">Diversity on e4</span>: It is very easy to become a committer on e4 - that's one of the purposes of an incubator. Basically, all it takes is a believable email to e4-dev@eclipse.org that you would like to work on something in the context of e4, and you will be nominated as a committer. Still, IBM has most of the commits in the e4 project. Who do you think is to blame for that? IBM? Because it is investing in a project whose goal it is to bring innovation back into the Eclipse Platform?</li><li><span style="font-weight: bold;">Diversity on the Eclipse Platform</span>: The last example I know of where people or companies wanted to contribute to the Platform but were not received with open arms is from about two years ago, when developers from WindRiver complained that their contributions did not make it into the Debug and Resources components. Where are we today? Both these components have committers from WindRiver, and Martin Oberhuber, a WindRiver employee, is a member of the Eclipse PMC. By the way, are those new committers contributing to those Eclipse Platform components full-time? No. (Just to be clear - I don't want to pick on WindRiver at all: I think it's great that they are in fact investing in the Eclipse Platform, even if it's just a little, when many other companies that benefit from the Platform don't invest anything at all.)<br />So, if you'd like to contribute to the Eclipse Platform on an ongoing basis, and feel that you are not "let in", please speak up so that we can fix the problem. I am pretty sure that this problem doesn't exist, and that instead the problem is more on the side of those who decide not to contribute, than it is on the side of the existing committers.<br /></li><li><span style="font-weight: bold;">Forking</span>: As of lately, this is easier than ever. Eclipse projects are now <a href="http://dev.eclipse.org/git/">mirrored as Git repositories</a>, starting with those that are using CVS for the main development. Knock yourself out, and don't forget to make the source available if you are creating derivative works. However, I don't think this is going to be a solution to the "tragedy of the commons" problem. I do hope this will make it easier to create private branches when your development timeline does not align with the one at eclipse.org, and you need to just fix something now. I also hope it will make it easier for contributors in general to provide patches that don't go stale.<br />By the way, the mirroring as Git repositories happened thanks to Denis and the webmasters at Eclipse, thanks to Shawn Pearce and the EGit and JGit team, and to a small amount thanks to Mike Milinkovich, the Eclipse Board of Directors, and your committer representatives on the board. If you are interested in details, see <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=280583">the bug</a> Chris Aniszczyk opened on June 17th just after Doug Gaff and I were able to convince Mike Milinkovich and the Board (<a href="http://www.eclipse.org/org/foundation/boardminutes/2009_06_17-18_Minutes.php">minutes</a>) that it was important to make this happen.</li><li><span style="font-weight: bold;">The Foundation is doing concrete work to help</span>: Mike has mentioned some of the things that are planned for 2010 <a href="http://dev.eclipse.org/blogs/mike/2009/11/30/dear-bjorn-go-away/">on his blog</a>: "a branded Eclipse forge hosted elsewhere (e.g. IP Policy free), Git support for the whole community and major improvements in hosted build and test at eclipse.org." I believe that the Eclipse Foundation staff, and Mike Milinkovich as the executive director, are doing a pretty good job, and they are also actively trying to get more involvement by other companies and individuals for core projects at Eclipse. The board of directors even made this a strategic goal for the Eclipse Foundation this past June<sup>1</sup>.<br /></li></ul>So overall, my comment would be "step up, or shut up". If you care about the future of Eclipse, pick a component or feature in one of the core projects that is critical for your use of Eclipse and help what you can. I would put at least the following in the "core projects bucket": Equinox, Eclipse Platform (with SWT, JFace, Workbench, Resources, Debug, Text, etc.), EMF, and GEF. If you think another project belongs in there, pick it instead and help there.<br /><br />Now for the definition of "help", I would recommend that you focus on a narrow enough subpart so that you can follow along for the next little while (like, for example, a year). Spend some time on the newsgroup/forum, read and understand the code, watch incoming bugs, find out who is the current maintainer, contact them and let them know you are interested in helping, and so on. This does not have to take a lot of time, but there is probably a lower limit of perhaps one or two hours per week. Convince your manager that doing this is important for the company, since they have software products that rely on the component or feature in question. You can also argue that investing a little time will help improve your skills. In fact, the latter point is a motivation that works even if you don't have an employer, if for example you are a student, or self-employed, or just not employed at the moment.<br /><br />What's in it for you? Potentially fame, when your name starts appearing in Eclipse <a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.tests.databinding/src/org/eclipse/jface/tests/databinding/BindingTestSuite.java?view=markup">source file headers</a>, or in <a href="http://www.eclipse.org/projects/ip_log.php?projectid=eclipse.platform">IP logs</a> (which by the way are another good way to measure project diversity). You'll learn about "<a href="http://www.eclipsecon.org/2005/presentations/econ2005-eclipse-way.pdf">the eclipse way</a>", the development process that allows us to ship on time and with quality, every year, for the last nine years. Finally, you'll have the warm fuzzy feeling that comes with ensuring the future of a core piece of technology that is being used by millions of users. Of course, you could help an Apache project, or Linux, or Mozilla, or on SourceForge or GitHub, but chances are (if you are reading this on Planet Eclipse) that your job indirectly depends on the future of Eclipse - not Apache, Linux, or Mozilla.<br /><br /><br /><span style="font-size:78%;">(Image © Zen Sutherland, http://www.flickr.com/photos/zen/241745451/sizes/o/, licensed under Creative Commons by-nc-sa 2.0)<br /></span><br /><br /><sup>1</sup> You have to read between the lines for this, not sure if newer board minutes have more detail. The <a href="http://www.eclipse.org/org/foundation/boardminutes/2009_06_17-18_Minutes.php">June board minutes</a> state: "<span lang="en-US">In discussing the strategic goals of the Eclipse Foundation, the Board indicated that diversity on e4 was of strategic importance to the Eclipse Foundation. In addition, it was important to continue to grow a diversified revenue model. As a result of the discussion, these two concepts were introduced into the Strategic Goals of the Foundation.</span>" Since a strategic goal that focuses solely on e4 seems a little odd, this has been generalized to apply not only to e4 but to other platform-y projects at Eclipse, I believe the wording is "Ensure adequate resources are invested in the core technology platform".Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com18tag:blogger.com,1999:blog-17547394.post-30274681631323142532009-11-24T01:07:00.001-05:002009-11-24T01:07:28.320-05:00OpenSocial (iGoogle) gadgets in EclipseSome of you may have seen this already, in the e4 <a href="http://download.eclipse.org/e4/downloads/drops/S-1.0M2-200911201200/e4-news-M2.html">M2 new & noteworthy</a> document: We are bringing Eclipse and the Web closer together. This work, a collaboration between <a href="http://blog.benjamin-cabe.com/">Benjamin Cabé</a> of Sierra Wireless and myself, is happening in the <a href="http://www.eclipse.org/e4/">e4 project</a>, which is the incubator area where we work on new technology, mostly for the Eclipse SDK 4.0 release planned for Summer 2010. (Some of the technologies developed in e4 may make it into the 3.x stream<sup>1</sup> as well.)<br /><br />Concretely, we are opening Eclipse for a whole new world of UI components called <a href="http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html">OpenSocial gadgets</a>. You have probably seen gadgets in action already, on iGoogle homepages. You can find gadgets that, for example:<br /><ul><li>display your Remember the Milk to-do list,</li><li>show your Twitter feed (with updates every x minutes),</li><li>provide your GMail inbox,</li><li>show a calendar, or, most importantly:<br /></li><li>display the "cat photo of the day". :-)</li></ul>Normally, gadgets would be hosted inside iframes on a web page. A web page that hosts gadgets, usually with the help of some server-side infrastructure, is called an OpenSocial gadget container. Many social websites are OpenSocial gadget containers - in fact, it looks like <i>every</i> social website except for Facebook is an OpenSocial gadget container - for example iGoogle, hi5, LinkedIn, MySpace, orkut, Friendster, Ning, XING and many others. Check out the <a href="http://www.opensocial.org/">OpenSocial web site</a> and scroll down for the full list. Most (if not all) of these sites use the <a href="http://incubator.apache.org/shindig/">Apache Shindig</a> reference implementation.<div><br /></div><div>In Eclipse, OpenSocial gadgets are hosted as views. This is what it looks like:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_9mAUrmH9eMo/Svt5Xpe6OHI/AAAAAAAAC6E/q1sMyV-MdcE/s1600-h/gadgets.png"><img style="cursor: pointer; width: 400px; height: 282px;" src="http://2.bp.blogspot.com/_9mAUrmH9eMo/Svt5Xpe6OHI/AAAAAAAAC6E/q1sMyV-MdcE/s400/gadgets.png" alt="" id="BLOGGER_PHOTO_ID_5403045625140492402" border="0"></a><br /><div style="text-align: left;"><br />More information, including how you can contribute, is available on <a href="http://wiki.eclipse.org/E4/OpenSocialGadgets">this wiki page</a>. You can also <a href="http://download.eclipse.org/e4/downloads/drops/S-1.0M2-200911201200/index.html">download e4 M2</a> and play with it, or install the feature into a 3.5 or 3.6 build as described on the wiki page.<br /><br />I think this is really exciting, and potentially an important part of the future of Eclipse. Here is why:<br /><br /></div><div style="text-align: left;">1. <i>It makes it easy to add a new view (or editor) to Eclipse. </i>Just write HTML, CSS, and JavaScript, and you don't even have to know that the gadget is going to be hosted in an Eclipse application. All the usual web arguments apply - zero install, all you need is a URL, proper sandboxing, etc.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">2. <i>It brings Eclipse and the "Open Web" closer together. </i>Web UIs are becoming increasingly important, and who knows, we may at some point want to run a full-blown IDE in a browser. But until then, we need a way to take advantage of the web without losing everything that we already have - supporting the existing Eclipse plug-ins is important for the forseeable future. By bringing the web to Eclipse instead of bringing Eclipse to the web, we can get the best of both worlds, if we can ensure that gadgets can become first class citizens in a desktop Eclipse application. (See 4. for what I mean by "first class Eclipse citizen".)</div><div style="text-align: left;"><br /></div><div style="text-align: left;">3. <i>It can make Eclipse more social. </i>At this point, our implementation does not support the "social" part of OpenSocial gadgets, but if we added that support, it could serve as another integration point for plug-ins, similar to how the common resource model (projects/folders/files) is an important "common currency" for IDE plug-ins.</div><div style="text-align: left;"><br /></div><div style="text-align: left;">4. <i>The OpenSocial specification could benefit, too.</i> We have ten years of experience with Eclipse as a platform or, as I like to call it, as a client-configured mashup platform. Users can start with a minimal platform, add a whole bunch of plug-ins and get an application where individual pieces work together seamlessly. (OK, I admit, it's not seamless in some cases, things don't always work together well, and if you add an insane number of plug-ins, Eclipse is slow and bloated, but I hope you get the idea.) I honestly don't know which other platform has come as far as Eclipse has in terms of integration of heterogeneous components. If you look at examples of the kind of integration and seamlessness I list below, only the first two are currently addressed by the OpenSocial gadgets specification. Many of the other "integration points" that we offer in Eclipse would make sense for OpenSocial as well, if the goal is to support more than a bunch of independent gadgets that sit next to each other on a web page. Here is a partial list of what we call the <i>Eclipse Application Services</i> a.k.a. "the twenty things":</div><div style="text-align: left;"><ul><li>Editing preferences in a consistent way.</li><li>A common mechanism for localizing strings.</li><li>Providing and listening to the current window-level selection.</li><li>Being able to start long-running operations, with progress reporting and the ability to cancel.</li><li>Indicating unsaved changes and prompting to save on close.</li><li>Common undo and redo operations.</li><li>Persisting UI state (e.g. column widths, sorting, etc).</li><li>Error reporting.</li><li>Common dialogs for common tasks.</li><li>Contributing menu and toolbar items to a shared area (global menu or toolbar), or even to other views and editors in form of additional items in local menus or toolbars.</li></ul><div>For the full list in draft form, and more details, check out the <a href="http://wiki.eclipse.org/E4/Eclipse_Application_Services">Eclipse Application Services wiki pages</a>. Ignore the fact that most of these wiki pages describe API in Java - it wouldn't be hard to specify similar or equivalent API in JavaScript as well. We still have to find out how best to interact with the OpenSocial community, and if they would be interested in taking their spec to the next level as hinted at above.</div><div><br /></div><div>On the Eclipse side, our plans for the coming weeks and months are roughly the following:</div><div><ul><li>Complete and solidify our implementation, which currently has high <a href="http://www.joelonsoftware.com/items/2009/09/23.html">duct tape</a> content.</li><li>Investigate if we can reuse parts of Apache Shindig to make our job easier.</li><li>Offer Eclipse Application Services as so-called "features" that gadgets can (optionally) depend on.</li><li>Write example gadgets that show the kind of integration into Eclipse that we'd like to see.</li></ul><div>Do you have an idea for a gadget that you would like to see in Eclipse? Would you like to join the fun and become an e4 committer to work on this with us? Let us know on the e4-dev mailing list if you would like to participate, or send me a direct email. Bugs and enhancement requests can be filed in <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=e4">Bugzilla</a>.</div><div><br /></div><div>Plain old comments on this blog are welcome too, of course. ;-)</div></div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div><sup>1</sup> - Similar to what Apache did with its httpd project and the 1.3.x and 2.x streams, we are planning two Eclipse SDK streams going forward - regular releases on the 3.x stream (3.6, 3.7, 3.8 ...) with a focus on stability, and a parallel 4.x stream with the innovative stuff.</div></div></div></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com9tag:blogger.com,1999:blog-17547394.post-3335514993106021132009-10-25T06:00:00.000-05:002009-10-25T06:24:31.346-05:00Adventures into web UI landTo explore how easy or hard it would be to write a UI component using web technologies, and then integrate it as a first class citizen in Eclipse, I reimplemented the PDE "site.xml" editor for the 0.9 release of e4, using HTML, JavaScript, Dojo, and CSS.<br /><br />I thought it would be interesting to document the design decisions that I made for this. Since my experience with web UIs is somewhat limited, you should take the following with a grain of salt. I did, however, work on something that could be characterized as an "IDE in a browser" for over three years (2001-2004), so I don't consider myself a complete rookie. :-)<br /><br />Note that I won't talk about integrating the web UI component into Eclipse, this posting is just about the actual web UI component itself. The Eclipse integration is a related, but different story, that deserves its own post.<br /><br />Let's start with a screenshot of the original PDE editor. It has two panes, a tree on the left showing features and categories, and a bunch of fields on the right with which you can edit the currently selected object in the tree. Depending on the type of object, the right side shows different fields, for example feature environments if the selected object is a feature, or category ID, name, and description if the selected object is a category. To add new categories or features, there are some push buttons on the right side of the tree.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_9mAUrmH9eMo/StiOXaJW7fI/AAAAAAAAC3M/YBNREUOApr0/s1600-h/sitexml-original.png"><img style="cursor: pointer; width: 400px; height: 271px;" src="http://2.bp.blogspot.com/_9mAUrmH9eMo/StiOXaJW7fI/AAAAAAAAC3M/YBNREUOApr0/s400/sitexml-original.png" alt="" id="BLOGGER_PHOTO_ID_5393217086582877682" border="0" /></a><br /></div><br />We should be able to achieve a very similar look and feel with a piece of web UI, after all, the "flat look" of the PDE editors was an attempt to mimic the look of a web page.<br /><br />The first important decision I had to make was whether to generate the HTML, pre-filled with the data, on the server side. This has the advantage that the resulting HTML can be made to (somewhat) work even if the web browser displaying it has JavaScript disabled. You would probably use a server-side <a href="http://en.wikipedia.org/wiki/Template_engine_%28web%29">template engine</a> for this. If you follow the link, you can see one of the disadvantages of this approach - there are a bajillion template engines to choose from. Good luck with deciding which one! ;-)<br /><br />But seriously, I had other reasons for deciding to let client-side JavaScript fill in the data instead. For example, this approach scales better because the "filling in data" work is done on the client, with the server doing less work because it only serves raw data. Also, it makes it easier to handle dynamic changes to the data on the client side because there is only one way of turning data into populated widgets. Development and testing is easier because you avoid a complete layer of the cake - you don't need to restart the template engine or reload the template every time you make a change, instead you change the .html or .js file and reload the page in the browser. Finally, this approach quite naturally leads to an interface between client and server that could be used by other kinds of clients as well (you get an API if you decide to publish and maintain it).<br /><br />Oh and I forgot, it wouldn't be buzzword compliant - to claim you're doing Ajax means that you have to use <a href="http://ejohn.org/apps/learn/">JavaScript</a> and <a href="http://en.wikipedia.org/wiki/XMLHttpRequest">XMLHttpRequest</a>, and to be <a href="http://ajaxpatterns.org/RESTful_Service">RESTful</a> means that the server should serve raw data.<br /><br />I started with the HTML and CSS first, leaving the client-server communication for later. My first goal was to get the right kind of "look". Many things are easy to do in plain HTML, for example input fields and buttons, and the header area that says "Update Site Map". There were two things that are hard (or maybe impossible) with plain HTML: making the two panes resizable by the user, and displaying a tree of objects. I decided to use Dojo for these two things, because I had a little previous experience with Dojo, and because it had been IP-approved for use by Eclipse projects. Note that I didn't use Dojo widgets for buttons and text fields, mostly because I didn't like their Dojo-styled look and wanted the "plain" look that you get from plain buttons and plain text fields.<br /><br />For the resizable panes with a draggable splitter between them, I was able to use a Dojo BorderContainer, which is configured like this:<br /><blockquote style="font-family: courier new;"><pre><div dojotype="dijit.layout.BorderContainer" design="sidebar"<br /> livesplitters="false" gutters="false"<br /> style="width: 100%; height: 90%;"><br /></pre></blockquote>The tree is created dynamically from JavaScript as follows:<br /><blockquote><span style="font-family:courier new;"><pre>myTree = new dijit.Tree({<br /> id: "myTree",<br /> model: model,<br /> showRoot: false,<br /> getLabel: function(item) { /* code to return the label... */ },<br /> getIconClass: function(item, opened){<br /> /* code returning a CSS class for the icon */<br /> },<br /> onClick: function(item,treeNode) { /* ... */ }<br />});<br />myTree.startup();<br />dojo.byId("tree").appendChild(myTree.domNode);<br /></pre></span></blockquote>This creates a tree widget based on the model you are passing in, and puts it under the DOM node with the ID "tree". Of course, there is more code than what I am showing here, but I hope that the few snippets I am showing give you enough context to understand the rest.<br /><br />I initially ignored the server part completely and just hard-code some example data right in the JavaScript. This allowed me to rapidly test and develop the web UI in a browser. Actually, make that "in all the browsers I cared about". During development, I kept Firefox, IE, and Safari open to make sure it worked in all of them. Some of the things you'd like to do in CSS, in particular with respect to layout, don't work quite the same in all the browsers. :-)<br /><br />Here is the result, opened in a standalone web browser:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_9mAUrmH9eMo/SuQxCI5inzI/AAAAAAAAC4c/X7I8loOHCf8/s1600-h/site-editor.png"><img style="cursor: pointer; width: 400px; height: 238px;" src="http://1.bp.blogspot.com/_9mAUrmH9eMo/SuQxCI5inzI/AAAAAAAAC4c/X7I8loOHCf8/s400/site-editor.png" alt="" id="BLOGGER_PHOTO_ID_5396492166315024178" border="0" /></a><br /></div><br />My next decision was about the client-server communication. I decided to use JSON as the data transfer format, because, as you all probably know already, "<a href="http://www.json.org/fatfree.html">JSON has become the X in Ajax</a>" (quote: Douglas Crockford). There was a more pragmatic reason, too: the version of Dojo that I used was a bit older and didn't support trees backed by XML data. With a little help from Dojo, you can make HTTP requests without having to worry about browser differences.<br /><br />There is only one thing that is not obvious: if the web UI is in a file like "site-editor.html" that references the necessary CSS and JavaScript pieces, then how does it know its "input", i.e. which resource to operate on? Somehow, the web UI needs to get to know the full path to the site.xml file. One widely used approach for solving this problem is to (mis-)use the "anchor" part of the URL that the browser points at. So for example, if the browser's URL is <span style="font-size:85%;"><span style="font-family: courier new;">http://localhost:9234/pde-webui/site-editor.html#/myproject/site.xml</span></span> then it will request <span style="font-size:85%;"><span style="font-family: courier new;">/pde-webui/site-editor.html</span></span> from <span style="font-size:85%;"><span style="font-family: courier new;">localhost:9234</span></span>, followed by an attempt to find the anchor named <span style="font-size:85%;"><span style="font-family: courier new;">/myproject/site.xml</span></span> in the HTML. Even though it won't find this anchor, the <span style="font-size:85%;"><span style="font-family: courier new;">document.location</span></span> object will contain the full information. This means that our JavaScript code can just get the value of <span style="font-size:85%;"><span style="font-family: courier new;">document.location.hash</span></span> and then make a corresponding XMLHttpRequest to get data from the server, which it then uses to fill the widgets. Once you know about this technique (which by the way has some nice properties with respect to the back button and the browser history), you will start to notice its use in many existing and widely used web-based applications. Like for example, <span style="font-size:85%;"><span style="font-family: courier new;">https://mail.google.com/mail/#inbox</span></span>, or <span style="font-size:85%;"><span style="font-family: courier new;">http://www.facebook.com/home.php#/bokowski?ref=profile</span></span> :-)<br /><br />By now, if you are still following, we have a client-side web UI consisting of some HTML, CSS and JavaScript, that will access a server over HTTP to get the data that needs to be displayed. Let's now focus on the server part.<br /><br />Obviously, we need a place to serve our static .html, .css, and .js files. The canonical choice for this is to configure Jetty accordingly. I am instantiating my own instance of Jetty and instruct it to pick a port number for me. If I know that the web UI will only be accessed from the local machine, Jetty can be configured to only accept connections from localhost.<br /><br />For the RESTful interface, I implemented a servlet that<br /><ol><li>responds to a GET request with the data I need in JSON format, and that</li><li>accepts PUT requests when the user wants to save changed data.</li></ol>In reality, the servlet does a little more (like e.g. authentication), but this post is already pretty long and I need to gloss over some of the details to not bore everyone to death.<br /><br />Let me just add one more thing - how did I implement the part of the servlet that converts the site.xml file into the JSON format I needed?<br /><br />The most obvious approach would be to parse the XML as a DOM and then generate JSON based on that DOM. Instead, I decided to use EMF objects as an intermediate "format". My idea was that by using EMF, the example code could easily be adapted to any data model that's already EMF based, and XML files (assuming they have an XML schema) could then be considered a special case.<br /><br />If you have an XML schema, you can let EMF create an .ecore file for you (using the New EMF Project wizard). For my use case, I chose to not generate any Java code from the .ecore file, because the code that generates JSON works on any EMF model, using generic EMF calls. This means that it should be very easy to change the schema, or even to use the same code for completely different models.<br /><br />Just to be clear, if you know that the format of your XML never changes, or if you want to minimize the external dependencies of your code, or if you enjoy programming against the DOM API ;-), or if adding EMF as another "layer" disturbs you, it's perfectly fine to not use EMF. Maybe it would even make sense to use XML on the client side as well.<br /><br />Overall, I was pretty happy with the structure that I came up with and think that it can serve as an example of how to approach the task of writing a web UI component. And now I'm looking forward to your comments, especially ones that explain how I could have made better decisions!Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com4tag:blogger.com,1999:blog-17547394.post-77489997344173832022009-10-15T11:47:00.004-05:002009-10-15T13:57:30.898-05:00JSR 330 (Dependency Injection for Java) passed!Two days ago, <a href="http://jcp.org/en/jsr/detail?id=330">JSR 330</a> passed its <a href="http://jcp.org/en/jsr/results?id=4992">final vote</a>, and we now have a standard way to annotate Java classes for dependency injection. Thanks to the spec lead <a href="http://www.crazybob.org/">Bob Lee</a>, the JSR 330 expert group did its work in <a href="http://twitter.com/joshbloch/status/4847948425">record time</a>, <a href="http://code.google.com/p/atinject/">in the open</a>, and under <a href="http://www.apache.org/licenses/LICENSE-2.0">one of the most permissive licenses</a>.<br /><br />Because of the transparency of the expert group work, it is no secret that I am <a href="http://code.google.com/p/atinject/people/list">representing</a> IBM in that group. I even implemented the spec in order to understand it better, and <a href="http://groups.google.com/group/atinject-observer/browse_frm/thread/6eb81864296495e3#">made that implementation available</a> as open source in the context of the <a href="http://www.eclipse.org/e4/">e4</a> project, which is the place where Eclipse Platform folks can experiment with new technologies. (Btw, I intend to put javax.inject <a href="http://www.eclipse.org/orbit/overview.php">in Orbit</a> for use by other Eclipse projects.)<br /><br />I am happy with the current state of JSR 330 and am looking forward to working with the expert group on a planned maintenance draft that will define a portable configuration API. Because with such an API, it will be possible to reuse application code across different injector implementations.<br /><br />Note that postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions. Similarly, IBM's votes on JSRs don't necessarily represent my personal positions, strategies, or opinions. ;-)Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com2tag:blogger.com,1999:blog-17547394.post-73580605585933350932009-09-25T14:33:00.000-05:002009-09-25T16:17:07.492-05:00Embedding web UI components in Eclipse using e4The demand for software that can be accessed through a web UI is increasing. We already expect software for occasional use (e.g. online shopping, banking, filling out forms, ...) to be accessible from a browser, without having to install anything locally. Over the last few years, more and more producticity applications (email, documents, spreadsheets, etc.) have become available through browsers as well. It is only a question of time until software development tools (at least for a certain class of uses) will have to have a web UI as well. In fact, a few browser-based IDEs already exist, such as Mozilla's <a href="http://labs.mozilla.com/bespin/">Bespin project</a>, and a very recent example: <a href="http://mbed.org/democompiler/">embed</a>, a special-purpose IDE for embedded development.<br /><br />At the same time, locally installed "rich client" applications, especially software development tools, aren't going to go away soon - there is a huge investment in the tools we have today, and I don't expect that all of this will be reimplemented using other technology just because web UIs are now the cool new thing to do.<br /><br />So the obvious question is, how can we, the Eclipse community, prepare ourselves for the trend towards the web, while keeping our desktop users happy?<br /><br />One approach is to keep the current programming model and just "make the stuff run in a browser". Fundamentally, this is very hard because the existing code we have today is not written with a client-server separation in mind. To a certain extent, it can be made to work though, and we have two examples of this at Eclipse, in form of the <a href="http://www.eclipse.org/rap/">RAP project</a>, and the experimental "<a href="http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/e4-news-all.html#swt">SWT Browser Edition</a>".<br /><br />The basic idea behind <a href="http://www.eclipse.org/rap/">RAP</a> is to place all application and UI logic on the server, including all widgets and their state, and to render those widgets on the client in a web browser while sending user events back to the server. However, there are a couple of characteristics of RAP that limit its applicability: For example, the "stuff" you run in a browser will be a complete application as opposed to individual UI components, high-latency situations are problematic, and you cannot run application code on the client side. (I hope the RAP team will let me know in the comments if I got any of this wrong.)<br /><br />The work on <a href="http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/e4-news-all.html#swt">SWT BE</a> "browser edition" is another take at the same problem, taking, if you will, the opposite approach: Client code (application and UI logic) makes use of the SWT API and as such can run in a desktop situation just fine. For "making it run in a browser", all the code is cross-compiled - to JavaScript for the Dojo port of SWT, or to ActionScript for the Flex port of SWT. So in a nutshell, instead of placing all application code on the server as with RAP, all application code ends up running on the client, in a browser. The obvious problem with this approach is that you still need code that runs on the server, to at least send data to the client and to receive updated data from the client, and that more often than not, you will end up with too much code on the client for execution. Of course, you could rewrite your existing code and ensure a proper client-server split, but if you are rewriting it anyway, why not go all the way and rewrite it using HTML and JavaScript?<br /><br />For the e4 0.9 release, we have done the first step of exactly that - we rewrote or "cloned" an existing component using HTML, CSS, JavaScript, and Dojo on the client side. The idea is to gradually move certain components (not complete applications) over to use web technology, while still having these components appear in the desktop Eclipse client as first-class citizens. As a first example, we chose the PDE site.xml editor, because of its relative simplicity but also because it is a good representative of a whole class of form-based UI components in Eclipse. We wanted the end result to run in a regular browser, as well as an editor inside of Eclipse. Here you can see it running stand alone in a browser:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_9mAUrmH9eMo/Srwcwwru95I/AAAAAAAAC1E/J8kZZaEfZ-k/s1600-h/site-editor.png"><img style="cursor: pointer; width: 400px; height: 238px;" src="http://4.bp.blogspot.com/_9mAUrmH9eMo/Srwcwwru95I/AAAAAAAAC1E/J8kZZaEfZ-k/s400/site-editor.png" alt="" id="BLOGGER_PHOTO_ID_5385210878455904146" border="0" /></a><br /></div><br />To make the editor work in a regular browser, it had to have a "real" server-side counterpart. Luckily, Eclipse already ships with an embedded servlet container, Jetty. This means that the web UI editor could talk to a servlet running in the same VM as the embedded browser widget rendering the UI. This is not unheard of at all - the Eclipse help system is taking the exact same approach.<br /><br />However, just presenting the unchanged web UI in an embedded SWT browser widget - backed by IE if you run Windows, Firefox on Linux, and Safari on the Mac - is not enough. The editor would only be a first-class citizen in the Eclipse UI if, for example:<br /><ul><li>you didn't have to authenticate to the web UI every time you open an editor,</li><li>the editor signaled unsaved changes through the usual "*" in the editor tab, as opposed to an indicator in the editor itself,</li><li>you can trigger saving your changes using the menu (File>Save ),</li><li>etc.</li></ul>In other words, the editor needs to make use of appropriate Eclipse APIs that connect Eclipse UI components such as views and editors to their context: the Eclipse workbench. One of the goals of e4 has always been to simplify the core APIs, and to make them accessible from other programming languages. So in a sense, we have started to make this real by offering JavaScript APIs that can be called by web UI components: to signal that they have unsaved changes, to provide a callback that will save those changes, etc.<br /><br />Give it a try! After <a href="http://download.eclipse.org/e4/downloads/drops/R-0.9-200907291930/index.html">downloading the e4 0.9 SDK</a>, start it up with an empty workspace and create an update site project (Ctrl+3, 'nusp'). Add some features and categories to it using the regular PDE site.xml editor, save, and then right-click on the site.xml file and use "Open With" to open it with the web-based editor. It will look like this:<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_9mAUrmH9eMo/Sr0xHX1oWsI/AAAAAAAAC1M/i3K2oeqwdCw/s1600-h/e4-site-editor-integrated.png"><img style="cursor: pointer; width: 400px; height: 302px;" src="http://1.bp.blogspot.com/_9mAUrmH9eMo/Sr0xHX1oWsI/AAAAAAAAC1M/i3K2oeqwdCw/s400/e4-site-editor-integrated.png" alt="" id="BLOGGER_PHOTO_ID_5385514732132784834" border="0" /></a><br /><br /><div style="text-align: left;">Please leave comments if you have any questions. I will try to write up more about this in the next couple of days, going into more technical detail.<br /></div></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com6tag:blogger.com,1999:blog-17547394.post-41708766079888140682009-09-24T11:35:00.005-05:002009-09-24T13:32:57.574-05:00API compatibility mattersA few weeks ago, Palm has <a href="http://developer.palm.com/">released an SDK</a> called "Mojo" for their <a href="http://developer.palm.com/index.php?option=com_content&view=article&id=1772">WebOS</a>. They also offer Eclipse plug-ins that have been developed for and tested with Eclipse 3.4.2. I just read a <a href="http://www.eweek.com/c/a/Application-Development/REVIEW-Eclipse-Gets-Palm-webOS-Mojo-816169/">short review</a> of this Eclipse-based tooling and was happy to see the following:<br /><blockquote><span style="font-style: italic;">The WebOS plug-in is supposed to officially work with Version 3.4.2 of Eclipse (code-named Ganymede). However, I was able to successfully run it on Version 3.5 of Eclipse (code-named Galileo) without any problems.</span><br /></blockquote>It makes me happy to see real-world reports like this. They confirm that you can run plug-ins developed for older versions of Eclipse on more current versions. In the Eclipse community, we almost take this for granted and sometimes tend forget the effort involved in pulling this off. Because when you think about it, compatibility is only achieved when both sides do a good job of enabling compatibility:<br /><ul><li>On the Eclipse SDK side, we tend to think that we are doing good job of ensuring API compatibility between Eclipse releases, so that you can run older plug-ins on newer versions of Eclipse. Since Eclipse 1.0 (2001), we've had excellent rules in places around API compatibility, and if you want to read more I'd recommend you start at our "<a href="http://wiki.eclipse.org/API_Central">API Central</a>" wiki page. More recently, we've automated a lot of the necessary compatibility checking in form of <a href="http://www.eclipse.org/pde/pde-api-tools/">API tooling</a> that ships with the Eclipse SDK. I haven't seen anything like it for other languages or environment yet, but would like to hear if similar tooling exists elsewhere. C#? ActionScript? Let me know in the comments!</li><li>On the Palm Mojo side, the developers must have done a good job of only using documented APIs, and abiding by the contracts for those APIs. Because if you don't, all bets are off.</li></ul>Here is a quote from the 2001 article "<a href="http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html">How to use the Eclipse API</a>" by Jim des Rivieres, a recommended read for anyone developing Eclipse plug-ins:<br /><blockquote style="font-style: italic;">As the Eclipse platform matures and evolves, it will be the API contracts that guide how this evolution happens. Outside of these contracts, everything is unsupported and subject to change, without notice, and at any time [...]. Client code that oversteps the above rules might fail on different versions and patch levels of the platform; or when run on different underlying OSes; or when run with a different mix of co-resident plug-ins; or when run with a different workbench perspective; and so on. [...] To those who choose to ignore the rules, don't say that you weren't warned. And don't expect much more than a sympathetic "Told you so."</blockquote>Of course, in reality, life is never as easy and black-and-white as software developers would like it to be. Sometimes, the existing API doesn't work for your particular case, or there is no supported API at all. In these cases, however, you need to realize that by calling internals, you are assuming <a href="http://martinfowler.com/bliki/TechnicalDebt.html">technical debt</a>. The idea behind this metaphor, created by Ward Cunningham, is that you have taken a shortcut and need to pay up later, either in form of interest payments or paying back the principal. In concrete terms: Whenever a new version of the plug-ins you depend on comes out, you have the cost of testing that your code still works, and the cost of adapting to any change that may have broken your code. This is a recurring cost, hence the term "interest". If you want your code to run against both older and newer versions of your dependencies, the interest payments are much greater, because the problem is much harder. Often, you will need to use Java reflection to guard your calls to internals. Alternatively, you can pay back the "principal" at a later point in time, when the necessary API has been added, and get rid of your debt. You did file an enhancement request to get that API added, didn't you? Because if you don't, you'll be bound to pay interest forever!<br /><br />Every now and then, I encounter people who are hoping to get away without paying either interest or principal. And that's after our collective experience with how <a href="http://en.wikipedia.org/wiki/Collateralized_debt_obligation">schemes</a> based on trading debts can take the whole economy down! :-)Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com2tag:blogger.com,1999:blog-17547394.post-23187130484076442082009-03-20T16:11:00.005-05:002009-03-20T16:26:07.978-05:00Thank you!I am looking forward to attending my first <a href="http://www.eclipse.org/org/press-release/20090320_EclipseBoard.php">Eclipse Board</a> meeting on Monday. This first time, I will be a guest since my term of office starts in April. Unfortunately, I can only attend the second half because I am co-presenting a tutorial in the morning. Sorry about that, it won't happen again. ;-)<div><br /></div><div>Thanks to all who voted!</div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com3tag:blogger.com,1999:blog-17547394.post-18143248663023615532009-03-19T19:59:00.003-05:002009-03-19T20:10:03.271-05:00RCP Mail 2.0<div>Come to <a href="http://www.eclipsecon.org/2009/sessions?id=641">our EclipseCon 2009 tutorial</a> (Monday March 23, 8:00 - 12:00) if you would like to learn about best practices for data binding, commands/handlers/contributions, and the common navigator. Bring your laptop with a copy of <a href="http://download.eclipse.org/eclipse/downloads/drops/S-3.5M6-200903130100/index.php">Eclipse SDK 3.5 M6</a> for the hands-on excercises!</div><div><br /></div><div>Three RCP practitioners, and three Platform UI committers for a total of six people will help you understand and build RCP Mail 2.0. Should be fun!</div><div><br /></div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_9mAUrmH9eMo/ScLqk8cN2sI/AAAAAAAABic/RNS1CbA7EA8/s1600-h/rcpmail2-splash.png"><img style="cursor:pointer; cursor:hand;width: 400px; height: 242px;" src="http://1.bp.blogspot.com/_9mAUrmH9eMo/ScLqk8cN2sI/AAAAAAAABic/RNS1CbA7EA8/s400/rcpmail2-splash.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5315068430671272642" /></a>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com2tag:blogger.com,1999:blog-17547394.post-13482434023681858332009-02-23T16:10:00.001-05:002009-02-23T16:11:36.170-05:002009 Eclipse Board of Directors<div style="text-align: center;"><a href="https://foundation.eclipse.org/vote2009"><img src="http://www.eclipse.org/membership/vote2008/vote.jpg" /></a><br /></div><div><br /></div>You have probably seen <a href="http://dev.eclipse.org/mhonarc/lists/eclipse.org-members-committers/msg00005.html">Mike's email</a> - the elections for <a href="http://www.eclipse.org/org/elections/nominees.php">committer representatives</a> for the Eclipse Board of Directors is now open.<div><br /><div>Rather than explaining why you should vote for me :-), I thought it would be useful to summarize the key election facts:</div><div><ul><li>You are voting for a one-year term starting April 2009. Voting is open as of today, for three weeks until March 13, 3 pm Eastern time. Check out the <a href="http://www.eclipse.org/org/elections/nominees.php">committer candidates</a> and their vision statements.</li><li>To vote, check the email you received from emo@eclipse.org on Feb 20, 2009. It contains the <a href="https://foundation.eclipse.org/vote2009/">URL</a> for voting, as well as the required voting password.</li><li>The Board will have 24 directors, as follows:<ul><li>Sixteen directors for the <a href="http://www.eclipse.org/membership/showMembersWithTag.php?TagID=strategic">strategic members</a>, one seat per member.</li><li>Four directors from "<a href="http://www.eclipse.org/membership/vote2008/">sustaining members</a>". There are nine candidates, and sustaining members (companies) get to vote. This is the old "add-in providers" category but generalized to include "enterprise members" in the future.</li><li>Four directors representing the committers. There are six <a href="http://www.eclipse.org/org/elections/nominees.php">committer candidates</a>.<br /></li></ul></li><li>Each committer has one vote. Here are some important details:<ul><li>Committers who are employed by a member company can go ahead and vote. Note though that all votes from one company will be <a href="http://ed-merks.blogspot.com/2008/02/one-committer-one-vote.html">collapsed into a single vote</a>.</li><li><span class="Apple-style-span" style="">Individual committers, if they have not done so yet, must sign a membership agreement in order to be able to vote</span>. To understand why this is required, read <a href="http://www.eclipse.org/membership/become_a_member/committer.php">this page</a>, then read <a href="http://www.eclipse.org/membership/become_a_member/membershipProcess.php">this page</a> to make sure you fill out <a href="http://www.eclipse.org/org/documents/Eclipse%20MEMBERSHIP%20AGMT%202008_04_16%20Final.pdf">the form</a> correctly. No voting privileges without signing the form!</li></ul></li><li>In previous years, <a href="http://milinkovich.blogspot.com/2008/03/election-results.html">turnout was pretty low</a> - for example in 2008, only 148 of about 1,000 committers cast their vote. More votes will add weight to the positions of the committer representatives, so please vote now!<br /></li><li>There is more than one <a href="http://www.eclipsesoccerclub.com/board.shtml">Eclipse Board of Directors</a>, so be careful not to confuse the different <a href="http://www.firstcolonysoccer.com/club_pages/documents/Board_Volunteer_Document_08.pdf">board elections</a>. ;-)</li></ul></div><div><br /></div></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com3tag:blogger.com,1999:blog-17547394.post-9199106185578363632009-02-17T18:07:00.000-05:002009-02-17T18:12:30.945-05:00Eclipse in the Cloud<div><div>About a year ago, at EclipseCon, we showed a demo of how the Eclipse IDE could look like if it was browser-based, talking to an Eclipse server "in the cloud". The reactions were lukewarm: "Looks cool, but <a href="http://www.infoq.com/news/2008/05/e4-summit#view_23644">why</a> would I want to run an IDE in a browser?" "I have <a href="http://www.lemmster.de/blog/index.php/2008/03/20/173/#comment-23615">yet to see</a> web enabled IDEs as an industry trend".</div><div><br /></div><div>This industry trend is now starting to happen.</div><div><br /></div></div><div>On Thursday, Mozilla and their new <a href="http://labs.mozilla.com/2008/10/developer-tools-and-the-open-web/">developer tools lab</a> launched Bespin, an "<a href="http://labs.mozilla.com/projects/bespin/">experiment proposing an open, extensible web-based framework for code editing</a>". Within a few days, 30,000 people logged into their public server, 400 people joined their discussion group, about 50 bugs were filed, several of them with patches, and many articles, blogs and even a Wikipedia entry were written. Congratulations, <a href="http://galbraiths.org/blog/">Ben</a> and <a href="http://almaer.com/blog/">Dion</a> of Mozilla (and Ajaxian fame), on the successful launch!<br /></div><div><br /></div><div>We looked at Bespin and asked, wouldn't it be great if Eclipse could play in this space too? Wouldn't it be cool if we could implement a Bespin server using Eclipse plug-ins that already exist?</div><div><br /></div><div>Well... that Eclipse-based Bespin server is available now, after two days of development!</div><div><br /></div><div><a href="http://dev.eclipse.org/mhonarc/lists/e4-dev/msg00398.html">Simon Kaegi</a> and I locked ourselves into a room and just implemented it. Today, we are declaring success, and are sharing the code as part of the e4 project with anyone interested. If you would like to give it a spin, check out <a href="http://wiki.eclipse.org/E4/Bespin">this wiki page</a>.<br /></div><div><br /></div><div>The Eclipse IDE, as you know it, is an OSGi-based application, and is built entirely out of components (called plug-ins or bundles). Many of these components can run headless, on a server, such as the underlying resource model, the incremental Java compiler, etc. Using the headless components, it was very easy to implement the Bespin client-server API. Like Mozilla's Bespin server, our server supports browsing files and folders, and editing files. In addition to that, we implemented extra features such as showing compile errors and warnings, and checking out projects from CVS servers using anonymous CVS.</div><div><br /></div><div>Bespin already shows a lot of promise at this early stage. It consists of a surprisingly fast code editor written in JavaScript using Canvas, a file browser, and an emacs-like command line interface for issuing commands. There are two backend implementations provided by Mozilla, one in Python, and one in Java, and the browser-based client talks to the server using a RESTy API. Here is how it looks like:<br /></div><div><br /></div><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_9mAUrmH9eMo/SZsk5j0a2hI/AAAAAAAABcw/uPXbXP5rftk/s1600-h/bespin-eclipse.png"><img src="http://2.bp.blogspot.com/_9mAUrmH9eMo/SZsk5j0a2hI/AAAAAAAABcw/uPXbXP5rftk/s400/bespin-eclipse.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5303873557445138962" style="cursor: pointer; width: 400px; height: 346px; " /></a><br /></div><div><br /></div><div>If you would like to play with the Eclipse Bespin server, or work with us on it, check our <a href="http://wiki.eclipse.org/E4/Bespin">wiki page</a>. If there are any questions, hop on <a href="http://wiki.eclipse.org/IRC">IRC</a>, where we can be found on <a href="irc://irc.freenode.net/#eclipse-e4">#eclipse-e4/irc.freenode.net</a> or <a href="irc://irc.mozilla.org/#bespin">#bespin/irc.mozilla.org</a> as borisb6i and skaegi.</div><div><br /></div><div>P.S. Mozilla has a cool-looking and fast client, and Eclipse has a lot of experience with IDE features, and good amounts of code that can run headless. Sounds like a great opportunity for collaboration, doesn't it? Well, thanks to <a href="http://dev.eclipse.org/blogs/mike/">Mike</a> and the Eclipse Foundation who organized it, and Dion and Ben who are investing their time and some of Mozilla's travel money, we will have an in-person meeting on Thursday, in Ottawa, to talk about this. These guys are moving fast!</div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com18tag:blogger.com,1999:blog-17547394.post-19627459388457802492009-02-05T16:51:00.002-05:002009-02-05T17:05:23.474-05:00Bundle Marketplace: +1I fully agree with Gorkem Erkan that the Eclipse community should seriously consider building a <a href="http://www.gorkem-ercan.com/2009/02/bundle-marketplace.html">bundle marketplace</a>. In fact, I recently had the same idea (independently) as you can see <a href="http://twitter.com/bokowski/status/1032571945">here</a> on Twitter.<div><br /></div><div>In the Eclipse context, that bundle marketplace would probably consist of multiple overlapping sub-markets... with every Eclipse-based application defining a sub-market. For example, bundles that work with the Eclipse IDE, bundles that work with the Flex IDE, or the SAP IDE, or with IBM's Rational tools such as Team Concert. Also, at the RCP level, vendors could offer a basic application for free and offer upgrades as additional for-pay bundles.</div><div><br /></div><div>I think this an exciting idea. What do we need to do to make it happen? Would the <a href="http://www.eclipse.org/org/elections/">Eclipse Board of Directors</a> support this? Which members of the Eclipse community (other than <a href="http://www.threeriversinstitute.org/junitmax/subscribe.html">Kent Beck</a> ;-) ) would benefit the most, short-term?</div><div><br /></div><div>Looking forward to your comments.</div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com0tag:blogger.com,1999:blog-17547394.post-31559026109134614032008-10-16T11:48:00.000-05:002008-10-16T13:50:13.785-05:00Are you listening?<span class="Apple-style-span" style=" ;font-family:'Times New Roman';"><div style="border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 3px; padding-right: 3px; padding-bottom: 3px; padding-left: 3px; width: auto; font: normal normal normal 100%/normal Georgia, serif; text-align: left; "><div>Did you know that the Eclipse SDK alone has over 250 different listener interfaces? In the following screenshot, look at the size of the scrollbar slider!</div><div><br /></div><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_9mAUrmH9eMo/SNr8wzRrgvI/AAAAAAAAAq0/qIavMv8wIOk/s1600-h/listeners.PNG"><img src="http://3.bp.blogspot.com/_9mAUrmH9eMo/SNr8wzRrgvI/AAAAAAAAAq0/qIavMv8wIOk/s400/listeners.PNG" border="0" alt="" id="BLOGGER_PHOTO_ID_5249786230982017778" style="cursor: pointer; " /></a><br /></div><div><br /></div><div>This is only the tip of the iceberg - corresponding to all these listener interfaces, there are about 250 different Event classes. This is so that later on, additional event data can be added without breaking binary API compatibility by passing a dedicated event object to the listener. (<a href="http://borisoneclipse.blogspot.com/2008/09/accidental-complexity.html">Remember</a> that where we forgot to use event objects, we ended up with warts like IPerspectiveListener4.)</div><div><br /></div><div>To top it off, there are probably about 500 methods for adding and removing all these kinds of listeners. addLaunchLabelChangedListener/removeLaunchLabelChangedListener, addLocalSiteChangedListener/removeLocalSiteChangedListener, addLogEntryListener/removeLogEntryListener and so on.</div><div><br /></div><div>In the end, when you think about it at a more abstract level, there are only a couple of possible changes that can happen in a program. A value can change, from an old value to a new value. A set can change, by adding or removing elements. A list can change, by adding elements at a certain index, removing elements at an index, or moving or replacing elements.</div><div><br /></div><div>How about we use only three listener interfaces, IValueChangeListener, ISetChangeListener, and IListChangeListener? Or we settle on something that looks like <a href="http://www.eclipse.org/emf">EMF</a>'s <a href="http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.emf.doc/references/javadoc/org/eclipse/emf/common/notify/Notification.html">notification API</a>. We might need pre- and post-notifications, and maybe also changes to maps, so the resulting number of listener interfaces might be closer to ten. Definitely not 500 - and I only looked at the base Eclipse SDK...</div><div><br /></div><div>What do you think? Can we make the Eclipse API more consistent and uniform in this way? Do you agree that all these domain-specific listener interfaces, each with a corresponding event class, and add/remove methods, are a source of <a href="http://borisoneclipse.blogspot.com/2008/09/accidental-complexity.html">accidental complexity</a>, and settling on a small number of generic listener APIs can reduce <a href="http://dev.eclipse.org/mhonarc/lists/eclipse-incubator-e4-dev/msg00838.html">code bloat</a>?</div></div></span>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com6tag:blogger.com,1999:blog-17547394.post-35712335247858675692008-10-07T15:30:00.000-05:002008-10-07T22:38:38.323-05:00Avoiding BloatMartin Oberhuber asked on the e4 mailing list what had happened to the pervasive architectural themes that were identified at the summit, such as reducing bloat, too many listeners, and becoming more asynchronous. I started writing a response, focusing on one of the topics, bloat, and it quickly became more than just an email response so I am posting it here.<div><br /></div><div><div>Before we go into the details, let me state the obvious: It is pretty much guaranteed that we will cause more bloat, overall, for the case of the Eclipse SDK based on the new e4 platform, as long as that SDK still contains 3.x plug-ins that require compatibility layers. This is because all the old (bloated?) functionality and the new (lean?) functionality will be there at the same time.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_9mAUrmH9eMo/SOwm94IIBiI/AAAAAAAAAr8/wQ-QUokQeyQ/s1600-h/Copy+of+DSC00685.JPG"><img style="cursor: pointer;" src="http://2.bp.blogspot.com/_9mAUrmH9eMo/SOwm94IIBiI/AAAAAAAAAr8/wQ-QUokQeyQ/s400/Copy+of+DSC00685.JPG" alt="" id="BLOGGER_PHOTO_ID_5254617709714867746" border="0" /></a><br /></div></div><div><br /></div><div><div>It seems the best we can do is to avoid bloating the new platform itself, when it is used without any compatibility layers. Unfortunately, we have all these cool new technologies that we would like to use - EMF, CSS, declarative UIs, data binding, cross-compiling of Java to ActionScipt, being able to use multiple languages, client-server split, etc. Put them together and the likely result is bloat. Or is there a way to avoid bloat and use cool new technology at the same time?</div><div><br /></div></div></div><div>So what is bloat? Let's look at <a href="http://en.wikipedia.org/wiki/Software_bloat">Wikipedia's definition of software bloat</a> (thanks John Arthorne for pointing me to it):</div><div><br /></div><div><b><span class="Apple-style-span" style="font-style: italic;">Software bloat</span></b><span class="Apple-style-span" style="font-style: italic;">, also known as </span><b><span class="Apple-style-span" style="font-style: italic;">bloatware</span></b><span class="Apple-style-span" style="font-style: italic;"> or </span><b><span class="Apple-style-span" style="font-style: italic;">elephantware</span></b><span class="Apple-style-span" style="font-style: italic;">, is a term used in both a neutral and disparaging sense, to describe the tendency of newer computer programs to be larger, or to use larger amounts of system resources (mass storage space, processing power or memory) than necessary for the same or similar benefits from older versions to its users.</span></div><div><br /></div><div><div>Let me dive into one concrete example, to show why this is a hard problem:</div><div><br /></div><div><span class="Apple-style-span">Code bloat through redundancy, caused by low-level API</span> occurs when clients of a low-level API have to write the same boilerplate code over and over again. Think of all the code we have to write for SWT layouts, for example:</div><div><div></div><blockquote><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">Composite contents = new Composite(parentComposite, SWT.NONE);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">contents.setLayoutData(new GridData(GridData.FILL_BOTH));</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">GridLayout layout = new GridLayout();</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">layout.marginHeight = convertVerticalDLUsToPixels(IDialogConstants.VERTICAL_MARGIN);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">layout.marginWidth = convertHorizontalDLUsToPixels(IDialogConstants.HORIZONTAL_MARGIN);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">layout.verticalSpacing = convertVerticalDLUsToPixels(IDialogConstants.VERTICAL_SPACING);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">layout.horizontalSpacing = convertHorizontalDLUsToPixels(IDialogConstants.HORIZONTAL_SPACING);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">layout.numColumns = 2;</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">contents.setLayout(layout);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';"><br /></span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">Label label = new Label(contents, SWT.LEFT);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">label.setText(WorkbenchMessages.FileExtension_fileTypeLabel);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">GridData data = new GridData();</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">data.horizontalAlignment = GridData.FILL;</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">label.setLayoutData(data);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';"><br /></span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">filenameField = new Text(contents, SWT.SINGLE | SWT.BORDER);</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">data = new GridData();</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">data.horizontalAlignment = GridData.FILL;</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">data.grabExcessHorizontalSpace = true;</span></span></div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';">filenameField.setLayoutData(data);</span></span></div><div></div></blockquote><div>Whenever there is a low-level way of doing things, you can come up with a higher-level way and reduce the code size. Of course, you are only reducing the overall code size when the higher-level abstraction is used widely enough to amortize the cost of its implementation. In our SWT layout example, you could write instead:</div><div><div><span class="Apple-style-span" style="font-size:85%;"><span class="Apple-style-span" style="font-family:'courier new';"></span></span></div><blockquote><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">Composite contents = new Composite(parentComposite, SWT.NONE);</span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">contents.setLayoutData(new GridData(GridData.FILL_BOTH));</span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span"><br /></span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">new Label(contents, SWT.LEFT).setText(label);</span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span"><br /></span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">filenameField = new Text(contents, SWT.SINGLE | SWT.BORDER);</span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span"><br /></span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">Point defaultMargins = LayoutConstants.getMargins();</span></span></div><div><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">GridLayoutFactory.fillDefaults().numColumns(2).margins(</span></span></div><div><span class="Apple-tab-span" style="white-space: pre;font-size:85%;" ><span class="Apple-style-span" style="font-family:'courier new';"><span class="Apple-style-span"> </span></span></span><span class="Apple-style-span" style=";font-family:'courier new';font-size:85%;" ><span class="Apple-style-span">defaultMargins.x, defaultMargins.y).generateLayout(contents);</span></span></div><div></div></blockquote><div>Now this is looking a lot shorter, and maybe even more elegant. However, even if <span class="Apple-style-span" style="font-family:'courier new';">GridLayoutFactory</span> is used widely enough to amortize the additional footprint caused by its implementation, there are still two problems: first, the original code ran faster, and second, you now have to learn two APIs - the higher-level one, and the lower-level one when the abstraction gets in your way.<br /></div></div><div><br /></div><div>You can see where I am going - there is no clear cut solution to this. It is really a hard problem, and in many cases, we will have to trade off one of the factors disk size, memory size, CPU consumption against the others.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_9mAUrmH9eMo/SOwlmAgS--I/AAAAAAAAAr0/ggOfER24a34/s1600-h/Copy+of+DSC00889.JPG"><img style="cursor: pointer;" src="http://1.bp.blogspot.com/_9mAUrmH9eMo/SOwlmAgS--I/AAAAAAAAAr0/ggOfER24a34/s400/Copy+of+DSC00889.JPG" alt="" id="BLOGGER_PHOTO_ID_5254616200135244770" border="0" /></a><br /></div></div><div><br /></div><div>Taking it just a little further, here is another idea, taken from the <a href="http://en.wikipedia.org/wiki/Code_bloat">wikipedia article on code bloat</a>:</div><div><br /></div><div><span class="Apple-style-span" style="font-style: italic;">The difference in code density between various languages is so great that often less memory is needed to hold both a program written in a "compact" language (such as a domain-specific programming language, Microsoft P-Code, or threaded code), plus an interpreter for that compact language (written in native code), than to hold that program written directly in native code.</span><br /></div><div><br /></div><div>So if we had a domain-specific language for creating SWT widgets and specifying their layout, we could get away with no Java code at all! I don't know if the .class file is a space efficient encoding for SWT widget hierarchies and layouts, but even if it is, consider this: The byte code for creating the widgets will stay in memory for as long as its class is referenced. Chances are that this will be a very long time; at least for the time that particular part of the UI is materialized somewhere. By comparison, if we had a domain-specific language, it would have to be read once to create the widgets and layout, after which the memory could be freed.</div><div><br /></div><div>So maybe we can have our cake and eat it too! After thinking about this a bit, I am all excited about using cool new technologies, as long as they don't cause bloat.<br /><br /><div style="text-align: center;"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_9mAUrmH9eMo/SOwiVEMiPYI/AAAAAAAAArs/GKb6L4Q0xVI/s1600-h/Copy+of+DSC06054.JPG"><img style="cursor: pointer;" src="http://1.bp.blogspot.com/_9mAUrmH9eMo/SOwiVEMiPYI/AAAAAAAAArs/GKb6L4Q0xVI/s400/Copy+of+DSC06054.JPG" alt="" id="BLOGGER_PHOTO_ID_5254612610533440898" border="0" /></a><br /></div></div><div><br /></div><div>We also have to be very carfeful not to use multiple redundant technologies to achieve the same thing, because that is another source of bloat. As in, for example, letting everyone plug in their favourite domain specific language for creating SWT widgets and layouts. This kind of redundancy would be just as bad as redundancy through repetitive boilerplate code, so let's pick one way of doing declarative UIs!<br /></div><div><br /></div><div>Note that there are lots of other sources of bloat, for example, unneeded functionality, too many layers of abstraction, or unnecessary flexibility. I am running out of time but it is probably interesting to think about these as well. I'd like to know if you have any pointers for me in the comments!</div><div><br /></div><div>If avoiding bloat is one of the goals of e4, we need to keep this goal in mind all the time. Every bit of functionality should be pulling its own weight. For example, do not add convenience API unless its additional weight can be justified by reduced weight somewhere else.</div><div><br /></div><div>I believe we should start watching our weight from the very beginning, and from time to time, it is probably healthy to discuss the weight of the various pieces. I can't wait until we have some kind of continuous build in place, so that we can make it visible for everyone how big (or small!) the components are, and how they are growing (or shrinking!) over time.</div><div><br /></div><div>We could also borrow some ideas from the business world and introduce budgets. You want to provide a component for declarative UI? How about you get an allowance of 300 K? Would that be enough?</div><div><br /></div><div>What do you think?</div></div></div>Boris Bokowskihttp://www.blogger.com/profile/06344587055927544695noreply@blogger.com10