OSGi in Dublin
If anybody is going to be in Dublin next Thursday (Sept 9th), I’ll be talking about OSGi, Software Modularity and Single Sourcing. Details of the event can be found here. If anybody is going to be in the area, let me know. I’d love to catch up with some Eclipse folks over a few frosty beverages.
Help, I’m looking for directions — Eclipse Active Help
I know Eclipse ‘Help’ is not a very exciting topic, but today I found myself working with a little known secret of Help. Most people know that you can setup context sensitive help (Press F1 and bring up help for the specific workbench part under focus). However, did you now you do the opposite? That is, activate code in your RCP application from a link in Help?
Here’s the use case: Say you have created a chat client built on the Eclipse RCP Platform. Like any good software engineer, you’ve created extensive help content. In addition to Instructions, you want to provide links that actually open the dialogs, or perform the actions. Active Help is the solution.
In this example, I’ve added a link that opens the “Add Contact” dialog, directly from the “Adding a Contact” Help page.
Doing this is extremely simple too. On the Java side, you simply need to implement the ILiveHelpAction. Then, on the help side you simply add the following JavaScript to your help contents:
<a href='javascript:liveAction( "org.eclipsercp.hyperbola", "org.eclipsercp.hyperbola.ActiveHelpOpenDialogAction", "")'>Click here for a Message.</a>
The only thing to keep in mind is that the Action is not executed on the UI thread, so you may need to synchronize this yourself.
Why Choosel is based on GWT
The first part of my presentation focused on several design decision behind Choosel. The framework is targeting information visualization novices - those who are not familiar with information visualization and visual data analysis beyond the graphics encountered in everyday life. Two major design decision we made based on those constraints is choosing the web as the target platform and developing Choosel using GWT.
We assumed that those information visualization novices are more likely to look at smaller data sets (up to 5000 items), but are not willing to spent much time getting started with visual data analysis. This was the main driver behind the decision to develop a web-based environment, because this spares user the burden of installing software. We considered removing this entry barrier more important then scalability beyond several thousand data items. As our main goal was to a provide interactive information exploration environment, responsiveness was important and we decided to use primarily technology that runs on the user's computer and not on the server.
In Choosel, we leverage third party visualization components and toolkits such as the Simile Timeline, Protovis and FlexViz. In order to be able to integrate different technologies such as Flash and JavaScript in the browser, we decided to use a JavaScript based technologies. First, we developed a initial prototype using the dojo toolkit. However, it turned out that because of our software development skills and tool support for unit testing, refactoring, and debugging, we were able to develop the same prototype using GWT in about a quarter of the time. The current version of Choosel is based on GWT.
Here are the slides from my presentation:
Detecting browser height
This example uses the ExternalInterface to determine the height of the browser by calling the eval javascript function (it is a built-in function).
E.g.
Different browsers (NS, FF, Chrome, IE, Safari) obviously don't all support this call. So far the window.innerHeight property works on all of them except IE. For IE you can use this one (IE 7 and above I think?):
And if your browser is older you can try this one:
Browsers will also handle errors differently, so if you try to use one of those JavaScript functions in one browser you might get undefined return, and in another browser you might get an error dialog box.
Here is an example of this in action, it opens in a new browser window to show it properly.
If it was embedded on this page using an <iframe> tag then the size returned is that of the iframe, not the browser.
- Browser Height Example -
Obviously if you were interested in the browser width then you could do exactly the same thing but replace innerHeight with innerWidth and clientHeight with clientWidth.
Comments welcome.
Work Item Tagging: Communicating Concerns in Collaborative Software Development
After a round of minor revisions, the extension of our ICSE 2009 paper on tagging in software development has been accepted for the TSE Special Issue of Best Papers from ICSE 2009.
For the TSE paper, Peggy and I replicated the previously reported case study on how software developers use tags for work items in two ways:
- We extended the study of the Jazz team in several ways; and
- We conducted another case with a different team at IBM that was not as likely to be biased towards using the tagging feature.
For the Jazz case study, we analyzed another year of archival data on the tagging activities; we further observed the team and tagging of work items through an additional 5 more months on-site and we conducted interviews with two additional team members. For the second case study, we observed a different group of developers for 2 weeks, we conducted interviews with 6 individuals of various roles and we analyzed tagging data from a one year period. Many of the original findings were replicated through these additional case studies, but the key differences in the extended paper are that:
- Our findings on the collaborative aspects of tagging are more comprehensive because of the extended ethnography and additional 8 interviews over both cases.
- The categorization for the types of tags used is treated much more thoroughly with new categories emerging from the analysis (many across both cases).
This is the abstract of the paper:
In collaborative software development projects, work items are used as a mechanism to coordinate tasks and track shared development work. In this paper, we explore how “tagging”, a lightweight social computing mechanism, is used to communicate matters of concern in the management of development tasks. We present the results from two empirical studies over 36 and 12 months respectively on how tagging has been adopted and what role it plays in the development processes of several professional development projects with more than 1,000 developers in total. Our research shows that the tagging mechanism was eagerly adopted by the teams, and that it has become a significant part of many informal processes. Different kinds of tags are used by various stakeholders to categorize and organize work items. The tags are used to support finding of tasks, articulation work and information exchange. Implicit and explicit mechanisms have evolved to manage the tag vocabulary. Our findings indicate that lightweight informal tool support, prevalent in the social computing domain, may play an important role in improving team-based software development practices.
Synchronized Scrollbars
I've written a utility class called LinkedScrollers that synchronizes the scrolling of two Scrollers. It has 5 public properties:
- enabled (defaults to true) - set to false to allow scrollbars to move independently
- scroller1 - the first Scroller
- scroller2 - the second Scroller
- component1 - the first SkinnableComponent, e.g. List, TextArea
- component2 - the second SkinnableComponent (List, TextArea, etc)
So another solution is to set the component1 and component2 properties to the two SkinnableComponents that you want to link (Lists, TextAreas, etc). It should work for any SkinnableComponent that contains a "scroller" skin part.
E.g.
Here it is in action, view source enabled (right click on the example below):
As you might guess, this follows on from my previous post on Spark TextArea With Line Numbers.
PlanetEclipse in March 2005
What do the following people have in common:
- Andre Oosthuizen
- Ed Burnette
- Euxx
- Frank Sauer
- Gunnar Wagenknecht
- Luis de la Rosa
- Martin Perez
- Vasanth Dharmaraj
They were the original 8 feeds on PlanetEclipse. If you are interested in some of the first posts checkout this link. Or, you can browse through time here.
For those of you that don’t know, planeteclipse is open to committers, contributors, or anybody with a passion for Eclipse. If you have something to say, feel free to request that your feed be added (checkout the guidelines first).
How Information Visualization Novices Construct Visualizations
Together with Melanie Tory and Margaret-Anne Storey, I investigated how information visualization novices construct visualizations in a laboratory setting. Our research paper "How Information Visualization Novices Construct Visualizations" was accepted for presentation at IEEE InfoVis 2010.
Here is the abstract of our paper:
It remains challenging for information visualization novices to rapidly construct visualizations during exploratory data analysis. We conducted an exploratory laboratory study in which information visualization novices explored fictitious sales data by communicating visualization specifications to a human mediator, who rapidly constructed the visualizations using commercial visualization software.
We found that three activities were central to the iterative visualization construction process: data attribute selection, visual template selection, and visual mapping specification. The major barriers faced by the participants were translating questions into data attributes, designing visual mappings, and interpreting the visualizations. Partial specification was common, and the participants used simple heuristics and preferred visualizations they were already familiar with, such as bar, line and pie charts.
From our observations, we derived abstract models that describe barriers in the data exploration process and uncovered how information visualization novices think about visualization specifications. Our findings support the need for tools that suggest potential visualizations and support iterative refinement, that provide explanations and help with learning, and that are tightly integrated into tool support for the overall visual analytics process.
Spark TextArea with Line Numbers
The line numbers use the same size font as the TextArea.
It is very simply to use, simply set the skinClass property in mxml like this:
If you want a horizontal scroll bar on the TextArea, then set lineBreak="explicit" and the horizontal scrollbar will appear.
Here is an example of it in action (right click to view source).
It would be very easy to modify this skin to make it resizable by adding a resize handle in the bottom right corner. Look at the source code from my previous blog post on Resizable Controls, specifically the flex.utils.spark.resize.ResizableTextAreaSkin class, it uses a custom skin for the Scroller, which adds the resize handle.
Flex 4 Spark Resizable Controls
I've created a bunch of skins for many of the common Spark components that allows them to be resized. Each of these skins contains a resizeHandle that when dragged allows the control to be resized. There are two resize handle classes that you can use, the default is called flex.utils.spark.resize.ResizeHandleLines. You can replace every occurrence of that class with flex.utils.spark.resize.ResizeHandleDots if you prefer.
Here are a list of resize skins:
- ResizableTextAreaSkin (skin for spark.components.TextArea)
- ResizableDropDownListSkin (skin for spark.components.DropDownList)
- ResizableComboBoxSkin (skin for spark.components.ComboBox)
- ResizablePanelSkin (skin for spark.components.Panel)
- ResizableTitleWindow (skin for spark.components.TitleWindow)
- ResizableScrollerSkin (skin for spark.components.Scroller)
- ResizableTitledBorderBox (skin for flex.utils.spark.TitledBorderBox)
- ResizableLabel (extends spark.components.Label, not a skin)
With the exception of the ResizableLabel class, all the others are Skins, and as such can be used very simply by setting the skinClass="flex.utils.spark.resize.___Skin" property to the appropriate skin.
Another option is to create a CSS style for ALL spark.components.Scroller classes to use the flex.utils.spark.resize.ResizableScrollerSkin class like this:
@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/mx";
@namespace spark "flex.utils.spark.*";
@namespace resize "flex.utils.spark.resize.*";
/* Make all Scroller's use the resizable scroller skin. */
s|Scroller {
skin-class: ClassReference("flex.utils.spark.resize.ResizableScrollerSkin");
}
</fx:Style>
** Note that I've renamed the Flex3 package flex.utils.ui.resize.* to the new Flex4/Spark package name flex.utils.spark.resize.*.
The most used skin is the ResizableScrollerSkin, it is used on TextAreas, Lists, DataGrids, Trees, ComboBoxes, DropDownLists, and anything else that uses a Scroller component. The way it works is to use a skin for the Scroller that adds the resize handle and uses custom HScrollBar and VScrollBar classes which leave room for the resize handle (the simplest way I could think to do it). Each of the resizable skins uses the ResizeManager class to handle the mouse events and resize the appropriate control.
The resizable ComboBox and DropDownList skins are slightly different in that they both save the size of the drop down list since it gets destroyed and re-created each time. It also sets the popUpWidthMatchesAnchorWidth="false" after resizing since the width no longer matches the anchor.
I've also added support for restricting the resize in only the vertical or horizontal direction. There are many ways you can do this, you can either set a style on the resize component:
resize-direction: vertical; /* or horizontal */
}
Here is an example of most of the skins, view-source enabled.
Diver in linux
And you may see this in the console:
Error occurred during initialization of VM
Could not find agent library in absolute path: /[path-to-plugin]/libsketch_linux32.so
Now, you may be surprised to find out that these errors may have nothing to do with open ports or whether or not the file listed exists. This is not Diver's fault. The client can't find an open port because the Java virtual machine couldn't start and open one. The Virtual machine couldn't start not because the listed library is missing but because you might not have some of the dependencies installed on your system. Unfortunately, the Java VM sometimes gives some pretty uninformative error messages.
Diver depends on the C++ boost libraries to do socket communication and multi-threading. It also uses boost to do multi-platform file system manipulation. Many distributions of linux come with boost installed. Some do not. If you have a debian-based version of linux, installing the required boost libraries is easy:
$ sudo apt-get install libboost-iostreams1.40.0 libboost-date-time1.40.0 libboost-filesystem1.40.0 libboost-system1.40.0 libboost-thread1.40.0
If you are running a redhat distro, you should be able to use a similar yum command. I hope that this all works for everyone.
Top 10 Eclipse Helios Features
Two weeks ago I asked you to think about high quality software that has been consistently delivered on-time. Think about software that is used by millions of people world-wide, built by hundreds of developers, free to use and open to everybody and anybody. Think about software that spans domains, runs on the smallest of devices and powers the worlds largest enterprises.
Any ideas? Yes I’m talking about Eclipse, and the next release — Helios — has arrived. (For an an ultra fast download try our Amazon Cloudfront mirrors). While everyone seems to enjoy kicking off new software projects, specifying requirements and designing the perfect system, only to have it fizzle out — Eclipse is Different. Eclipse Delivers.
For the past 2 weeks I’ve been counting down the Top 10 Features of Helios that I’m most excited about:
10. Resource Improvements
9. Feature based configurations
8. Improvements to API Tools
7. Java IDE Improvements
6. Target Platform Improvements
5. p2 API and the b3 Aggregator
4. MarketPlace Client
3. EMF, Riena and RAP integration
2. Git Support at Eclipse
And my number 1 feature of the Helios release is: Xtext, Version 1.0.
For those of you who haven’t heard of Xtext, Xtext is a programming language framework. Xtext bridges the gap between grammars, models and programming language tool support. Using Xtext you can create a powerful environment for your own DSL (domain specific language) or full fledged general purpose programming language.
There are a number of important features that make this such a powerful toolkit, including generated editors that support code folding:
styled content providers:
quick fix support:
quick outline view, and more:
There is also a number of tools to help you create Xtext grammars such as Grammar Content Assist:
Xtext also supports project builders and can even derive a grammar from an Ecore model.
I’ve been following Xtext for close to 4 years now (from its origins at openArchitectureWare and through the Textual Model Framework proposal), and it’s great to see this excellent tool declare its 1.0 release. Xtext also received much deserved praise for its outstanding website, large collection of getting started material and they even won the Eclipse Community Award for most Innovative Eclipse Project at EclipseCon this year.
Great work Michael Clay, Sven Efftinge, Moritz Eysholdt, Dennis Huebner, Jan Koehnlein, Sebastian Zarnekow, Heiko Behrens, Peter Friese and Knut Wannheden.
Throughout this series I’ve tried to cover a variety of different Eclipse projects, but this list is far from complete. Please feel free to leave a comment with your favourite Eclipse Helios feature. Or better yet, why not write an article about it?
Git Support, Top Eclipse Helios Feature #2
Only 1 more day until Eclipse Helios is release and we are down to my Top 2 features.
Over the life of Eclipse (Jeff McAffer tells me that he’s been working on Eclipse since 1999) a lot has changed. Eclipse started its life inside OTI/IBM. In November 2001 the Eclipse Consortium was announced and Eclipse was released as ‘Open Source’. For the next few years Eclipse grew, but was still mostly supported by a few large companies. New projects were proposed, new committers came on board, and Eclipse became the dominate player in the IDE space. But as the popularity of Eclipse grew, so did its diversification. Then in April 2010, David Carver noticed that the number of active individual committers (those not associated with any particular company) was tied with IBM for the top spot.
What does all this mean and what does this have to do with the Eclipse Helios release? Well, as Eclipse continues to diversify, the Eclipse foundation will need a software revision control system that supports this diversification. The Eclipse Helios release marks the beginning of this transformation. Number 2 on my Top 10 List is: Git Support at Eclipse.
Three important components make up the Git support at Eclipse: JGit, EGit and the Git Infrastructure. JGit is a pure Java library implementation of Git version control system. JGit is licensed under the EDL has a number of users, including the Netbeans Git support.
EGit is the Eclipse tooling, and is build on JGit. There is currently support for a number of Git features:
History view:
Repository View:
Patch Support:
The JGit / EGit team has excellent documentation and there is some great information on Git in general. Git is being worked on by Matthias Sohn, Shawn Pearce, Chris Aniszczyk, Mathias Kinzler, Stefan Lay, Robin Rosenberg and Christian Halstrick. However, a really big thank-you goes out to the past (and present) committer reps for bringing Git to Eclipse. The initial Git contribution provided a number of unique licensing challenges that required unanimous approval from the Eclipse board of directors. Git at Eclipse would not have been possible without their hard work.
In addition to the tool support, Eclipse.org has rolled out Git infrastructure for the community to make use of. There are Git mirrors for Eclipse projects and even Git repositories that some projects have started to migrate too. The big thank-you goes out to Denis Roy and Wayne Beaton for this. Git really is the future of Eclipse, and if all goes as planned, Git will be on my Top 10 List again next year.
EMF, Riena and RAP integration, Top Eclipse Helios Feature #3
Well here we are, it’s release week. Eclipse 3.6 — Helios — will be available on Wednesday June 23rd. It also means that I’m into my Top 3 features for this years release. For the past 7 days I’ve been presenting some of the New and Noteworthy features of this years release.
Number 3 on my Top 10 list is EMF, Riena and RAP integration.
I’ll be the first person to admit that when I first heard about the Rich Ajax Platform (RAP) I didn’t get it. I assumed RAP was about re-recreating the Eclipse UI in a browser. I, like many others, quickly realized that this is not the point of RAP. RAP brings the Eclipse programming model – Jobs API, JFace content providers, SWT API, Stacks, Forms, Selection Providers, etc… to the browser. If you appreciate the Eclipse programming model, and more importantly, if you have invested in the Eclipse programming model, then RAP is your best friend.
Of course you *can* re-create the Eclipse UI in the browser:
but this likely is not what you want to do. Instead, you want to reuse your existing software and theme it for a rich web experience.
The concept of reusing your hard work across multiple mediums is known as Single Sourcing. And it’s not just about the web; the new RAP protocol (not part of Helios) will open up a whole new world such as RAP on the IPad.
There are a number of notable new RAP feature in Helios including Opaque menus:
Drag and Drop:
New Themes:
Cheatsheet support:
Control Decorations:
and Graphics context support:
For these features, kudos goes out to Ralf Sternberg, Holger Staudacher, Tim Buschtoens, Ruediger Herrmann, Austin Riddle, Ivan Furnadjiev and Benjamin Muskalla.
While the new RAP features are incredible, RAP demonstrates the real power of Helios — cross product integration. Other Eclipse projects are starting to target RAP as runtime. In particular, Elias Volanakis has extended the Riena framework to make it work with RAP. You can now use the powerful Rigets on the web.
Finally, Kenn Hussey has extended the EMF Framework to target the Riach Ajax Platform as well as the RCP Platform.
Thanks everyone!
MarketPlace Client, Top Eclipse Helios Feature #4
As most of you know, Eclipse Helios will be released next week. For regular readers of my blog (and PlanetEclipse.org), you know that I’ve been counting down some of the new features available in this release. During this series I have received comments (both in the comment fields, and on places like twitter) that essentially read: I really like Eclipse except it doesn’t have an editor for XYZ. Or, when I get the following package, it has feature ABC which I don’t want. Obviously we can’t please all the people all of the time.
It was feedback like this that inspired Feature Number 4 on my Top 10 List: The Eclipse MarketPlace Client.
As we all know, Eclipse is much more than a Java IDE. In fact, Eclipse is an entire eco-system with thousands of plug-ins. Some of these plug-ins are packaged with the different Eclipse downloads. Other plug-ins are available as projects at eclipse.org. However, there are also thousands of plug-ins that are not hosted at Eclipse. Some of these are commercial tools developed for enterprise customers. Others (like one of my favourites — the vi plugin) have a small cost associated to help pay for the developers time. Finally, there is a large assortment of plug-ins available from a variety of other hosting sites. Finding and installing these components has always been a challenge, but with the Helios release this will all change.
The MarketPlace Client (MPC) makes it easy to browse and install 3rd party components. Available under Eclipse -> Help, this new feature should make it much easier to find the tools you need.
Also, unlike other ‘famous’ markets (or app stores), the Eclipse MarketPlace Client is plug-able and open, meaning vendors are free to create custom market places for their particular needs. Helios currently ships with 2 marketplaces, one from Eclipse.org, and the Yoxos Market hosted by EclipseSource. The two markets are slightly different in that the Eclipse MarketPlace lists plug-ins for a variety Eclipse versions, while the Yoxos MarketPlace is a curated repository of Helios related content.
It was the great work from David Green and Steffen Pingel that brought us this feature. Nathan Gervais from the Eclipse Foundation did the server side work, while Ian Skerrett was the point person behind all of this.
In addition to the MarketPlace, the Eclipse Foundation, with the help of Google, have launched the Eclipse Labs.
Eclipse Labs is a community of open source projects that build technology based on the Eclipse platform. It provides the infrastructure services typically required by open source projects, such as code repositories, bug tracking, project web sites/wiki. Eclipse Labs is hosted by Google Code Project Hosting, so it will be very familiar to developers already using Google Code Project Hosting.
Combing the market place with Eclipse Labs will make it much easier for developers to create, publish and distribute their products to the community.
Awesomeness in Helios
I have to admit that I honestly don't keep up with the latest improvements to the Eclipse IDE. The reason is simply practical. I work on making tools for doing research on IDEs. I would like my current project, Diver to be as compatible as is reasonable so that I can decrease the barrier to adoption. If I work with the "latest and greatest" version of Eclipse, I am just too tempted to use the "latest and greatest" features of Eclipse in my own tools, which means that people running the current release may not be able to work with what I am building. It's really just a matter of discipline.
But now that Helios is about to be released I've started to use it and I find it totally awesome. Ian Bull has been faithful to his top ten list of the newest and greatest features of Eclipse. I don't know if I will do the same, but I think I might report on the great things about Eclipse as I discover them.
So far, the number 1 through 10 greatest feature of Helios for me has been its new integration with the Eclipse Marketplace (and the Yoxos Marketplace catalog). I just recently had to change computers which meant that I also had to reinstall Eclipse. Normally, I would use Yoxos to create my own custom distribution of Eclipse, but I wanted to try Helios and all its cool new features. I use a number of 3rd party tools that aren't available in the standard Eclipse p2 repositories. For example, I work in academia which means that I write papers. I use LaTeX for writing papers, which is a surprisingly process to writing software. So, I use Eclipse to write text as well as software. It used to be total pain to search for my LaTeX plug-in, add its p2 repository to my list of "Available Software Sites", and install. That is no longer the case. Now, I can just load up my Eclipse Marketplace client and do a quick search for "LaTeX":
And there you go. No hassle, no fuss, I just install and that's it. It's beautiful.
As an aside (and a shameless plug), you can do the same thing with my project "Diver". Just load your Eclipse Marketplace client. A quick search for "reverse engineering" will point you straight to my favorite Eclipse tool ;-) :
p2 API and the b3 Aggregator, Top Eclipse Helios Feature #5
The official Helios release is less than 1 week away, and we are now into the Top 5 Features that I’m most excited about. Over the past week I’ve been highlighting some of upcoming features of the Eclipse Helios release. These features include: improvements to the Java Development Tools, Plug-in Development Environment, API Tools and the Eclipse Platform. Number 5 on my Top 10 List is: p2 API and the b3 Aggregator.
On Monday I discussed the importance of API when it comes to Eclipse projects. The p2 team has been working on the API for almost 3 years now and when Helios is released the p2 API will be official. What does this mean? It means you can build provisioning solutions around p2 without worry that the entire system will change from under you. In fact, I’ve been on both sides of the p2 fence: helping to define the API and then building the new Yoxos Launcher and Yoxos Enterprise solutions, using this technology. If you are building a system that needs SelfUpdate, Install, Uninstall and RollBack, and you have anything more complicated than a few static dependencies, you should really consider p2.
Here are some of the API highlights:
1. Support for multiple agents: This means you can manage multiple applications using a single controller. Once you create (or acquire) the agent, you can acquire agent services for: computing provisioning plans, working with metadata, working with artifacts, performing installs, etc… We make heavy use of this in Yoxos since our systems can both update themselves and manage your Eclipse installs.
2. A new approach to Queries: Querying metadata is an essential part of any provisioning system and p2 now supports both a p2 Query Language and a simple QueryUtil class to create the most common queries.
3. Java 5 generics: No we did not just leave all the Java 1.4 people behind and finally decide to move to Java 5; but rather, p2 now uses generics and down-compiles to Java 1.4 for backwards compatibility. This is a huge step forward for all the Java 5+ developers out there.
4. The operations API: The saying “Make easy things easy and hard things possible” has been on our mind as we designed the p2 API. While p2 has a very powerful planner (award wining planner I should add), the idea of crafting provisioning plans and executing these plans on an engine in order to affect a profile, is quite frankly — complicated! Using the operations API you can easily invoke common “operations” like update this item, or install this other thing. For an idea of what’s involved, please see our help documentation.
5. Real API: You will notice that we dropped provisional from many of our package names. Feel free to browse the p2 API Java docs.
There are also a number of improvements to the API to make things more consistent.
Thanks goes out to the entire p2 team for all the hard work (and heated discussions 
). In particular, John Arthorne, DJ Houghton, Thomas Hallgren, Susan McCourt, Daniel Le Berre, Simon Kaegi, Andrew Niefer, Henrik Lindberg, Matthew Piggott, Tom Watson and Pascal Rapicault.
In addition to the API, Steffen Pingel and Susan McCourt have worked on a new Discovery UI which can be used to provide a branded presentation of a p2 repository. Tools like Mylyn use this UI to make it easy for users to install Mylyn Connectors.
Finally, there are other projects around Eclipse.org that make working with p2 a little easier. PDE/Build, b3 and the newly proposed Tycho project make it possible to build p2 repositories. However, one project is the real workhorse behind the Helios release — the buckminster / b3 aggregator. The aggregator combines repositories from various sources into a new aggregated p2 repository. The aggregator has both a UI component and can be run headless (i.e., you can aggregate p2 repositories as part of your build process). Also, you can use the aggregator to get a detailed view of what’s in a p2 repository. For more information on this impressive tool, checkout their wiki page.
In addition to creating aggregated p2 repositories, the b3 aggregator can produce maven repositories.
Kudos for this work goes out to Thomas Hallgren, Henrik Lindberg, Filip Hrbek and Karel Brezina.
Target Platform Improvements, Top Eclipse Helios Feature #6
There are three large groups of artifacts that play a key role while writing software. There are the tools you use, the code you write and the libraries you depend on. There is a large body of research studying the cognitive support provided by software development tools. There is also a number of tool centric development models. Facilities like Yoxos and the Eclipse Market Place help you manage these tool chains.
Regarding source code management, there’s a endless debate over which tools, technologies and techniques we should use. In fact, most University curriculum’s spend a great deal of time on how to best architect, design, document, write and manage source code.
However, when it comes to the management of your 3rd party libraries — the code you need but you don’t write — this is very much an ad hoc process. Finding dependencies, including them on your build path, finding the corresponding source, determining (and locating) which version you need, etc… is mostly a manual process:
- Figure out what jar you need (Apache commons collections for example)
- Use google to search for the jar
- Add the jar to your path
- Run
- Look at the errors
- Did you have the right version
- Did you miss any dependencies
- Figure out what else you need to find
- GOTO 2
Lucky for us as Eclipse developers, PDE’s Target Platform and Target Definitions make this process effortless. You can define and share you dependencies with your team. If you are missing a dependency, it can be automatically provisioned and placed on your build-path.
Eclipse 3.6 is hitting the shelves (or at least the download mirrors) in 1 week, and to celebrate this release I’ve been counting down the Top 10 features I’m most excited about. Number 6 on my list is the Improvements to Target Platform Management.
In Eclipse 3.6 you will be able to search repositories and quickly add components from these repositories to your target platform (Ctrl+Shift+Alt+A).
In addition to this, a new quickfix allows you to search repositories for a missing import package and have a bundle supplying the package added to your target.
Finally, one of the biggest headaches for release engineers is collecting all these bundles that constitute your target. There is now a new export wizard that will export all the bundles in your target to a single directory. The tool will also generate a p2 repository. This repository can then be used in your build as a repoBaseLocation.
A big thanks goes out to Chris Aniszczyk and his army of Minions for this work 
.
Java IDE Improvements, Top Eclipse Helios Feature #7
As Eclipse committers, we spend lots of time emphasizing that Eclipse is not just an Integrated Development Environment. Eclipse is a framework, a tooling platform, a collection of run-time technologies, an eco-system, etc… However, at the end of the day, an IDE is the primary use of Eclipse for many people.
As we approach the next major release of the Eclipse platform — Helios — I’ve been counting down the features I’m most excited about. Number 7 on my list are the Enhancements to Eclipse as an IDE. These are features that will make your life easier as a developer (many of these features are Java specific, but not all).
The Java Development Team has released a number of new code formatter options:
While these are cool, the most exciting one (in my opinion) is the ability to disable formatting for certain code blocks
There are even a number of improvements to comment formatting.
As well as code formatting, the JDT team has introduced some new capabilities including: a breakpoint details pane
object instance counts
and static analysis improvements:
Huge kudos go the very active JDT team, including: Jayaprakash Arthanareeswaran, Deepak Azad, Frederic Fusier, Walter Harley, Ayushman Jain, Satyam Kandula, Markus Keller, Dani Megert, Kim Moir, Michael Rennie, Srikanth Sankaran, Olivier Thomann, Raksha Vasisht, Curtis Windatt and Darin Wright. Over the next year the JDT team will be focusing on Java 7 support. If you are interested in helping with this effort, why not get involved?
In addition to Java specific enhancements, the Eclipse Platform team has been working on general IDE improvements. One feature that really caught my eye was improved patch support. Last year the Platform team improved the Java Compare Editor. However, these changes did not extend to the apply patch wizard. As of Eclipse 3.6 this doesn’t matter because you can now use the synchronize perspective to apply patches:
This makes patch review a much easier process, especially since you can now apply a patch directly from a URL:
The Platform team (especially Tomasz Zarna and Szymon Brandys) deserve the credit for this work. Thanks everyone for making my life as a Java Developer easier.
Improvements to API Tools, Top Eclipse Helios Feature #8
I’ve been thinking a lot lately about what defines an Eclipse project? Not in the literal sense (a project hosted at eclipse.org that follows the EDP), but rather, what technical qualities do all Eclipse projects share.
Years ago the answer was simple, extensible IDEs. More recently Eclipse was defined as a tooling platform (for everything and nothing in particular), but when you start to look at where Eclipse projects are being used (Eclipse RT and modelling projects in particular), you realize that ‘a tooling platform’ doesn’t begin cover the spectrum.
Even eclipse.org has got out of the business of defining Eclipse. And while defining ‘Eclipse’ might not even be possible, there are a few technical qualities that all Eclipse projects share:
1. OSGi Based (most projects produce OSGi bundles)
2. A strong commitment to API
3. Meaningful versions
It’s the last two points that I want to focus on here.
Most Eclipse projects defined their versions based on API. We don’t use version sequences like 3.0, 3.1, 95, 2000, XP, 7. Instead, Eclipse projects define their versions such that a change in a version number indicates API compatibility (or incompatibility). There was an excellent tutorial at EclipseCon on this topic, and I believe that the connection between API and versioning is so important that it should be part of the undergraduate curriculum for software engineering. Like many software engineering activities, manging the relationship between your API and version number is challenging, but it can be aided through tool support. Lucky for us there is an entire Eclipse component dedicated to API tooling.
As we approach the Helios release, I’ve been counting down the Top 10 Features I’m most excited about. Number 8 on my list is Improved API tooling support.
API tooling has been included in Eclipse for a number of years now. When you enable API tooling as consumer of API, you can identify when you are using methods you shouldn’t be:
Producers of APIs can use the tooling to help identify when they have ‘broken’ API:
While these features have been around for a number of years now, there are some noteworthy additions to API tooling. There is now a launch configuration which can be used to track API usage and generate HTML reports. This allows producers (and consumers) to see who is accessing non-API packages / classes / methods:
While this is valuable information, most most exciting advancements of API tooling is the new Migration Report. Using the migration reports we can determine if our bundle(s) can be (easily) migrated to a new version. For example, if the API producer decided to change the signature of their apiMethod to include a new parameter (and they properly released version 2.0 of their bundle), we could run the migration report and as a consumer. Doing so would uncover any migration issues. In particular, on Line 10 in the doSomething method, we invoke a method that no longer exists.
More information on the migration tasks can be found on the Eclipse help system. Thanks to Chris Aniszczyk, Michael Rennie, Darin Wright and Olivier Thomann for this work.
Note: If I missed someone in the kudos, please let me know. I do my best to track down who worked on each feature .
