Eclipse 3.5.1 was just released! This is a service release as part of the Eclipse Galileo release train.
Inside Eclipse, you can use p2 to update with this URL:
If you’re only interested in Equinox, you can grab it here:
Finally the readme is here:
So what are you waiting for, update to get the latest bugfixes!
If you want to live on the bleeding edge, check out the latest Eclipse 3.6 (Helios) milestone.
Git has been gaining some traction in the Eclipse community as of late.
From the birth of the EGit project at Eclipse and the recent approval of JGit to be hosted at Eclipse as a sub project of the EGit project, good things are coming. Why should you care about Git?
Git is pretty popular these days as evident by some of the open source projects out there using Git:
Apache is even rumored to be switching, at the moment they have a public GIT mirror.
Git is also fast and efficient. In some of my testing, Git produced significantly smaller repositories than SVN did. In terms of speed… I think Git’s ability to do branching cheaply is one of its biggest assets. In the end, I think the most important feature of Git is that it significantly lowers the barrier to contribution. People are able to easily branch your work and you can pull at a later time. I’m not a Git expert by any means yet, but here are some things that have helped me along my Git journey:
In the Eclipse world, I see a move towards Git as the smart thing to do. It would make it easier for the Eclipse community to contribute code versus our current model. It would also help the many companies out there that maintain their own copies of Eclipse and patch things as necessary because of their release cycles. The more I look at it, I can’t come up with many reasons why Eclipse shouldn’t move to Git. Here are some current happenings:
If Git is important to you at Eclipse, I encourage you to get involved with the EGit project via their mailing list.
Eclipse has earned a reputation of being one of the best IDEs in existence. While it has become a lot more than that in many ways, its roots and its focus have always been the user facing aspects. That is probably the reasons why certain other aspects like the PDE build have been a bit neglected for quite a while. Between the ugly map files, the dependence on a target platform and its disability to run JUnit 4 tests it feels like there is quite some room for improvement.
I appreciate all the effort that went into the current state of the PDE Build, and there is quite a lot that it offers: Checking of OSGI access rules, validation of extension and extensions points, multi-platform builds, generation of p2 metadata for update sites among other things. I want to take a look at some of the recent and ongoing developments that build upon that legacy.
The b3 project is currently in incubation at eclipse.org. Its goal is basically to be to the PDE build what p2 was to the update manager: A revised, more powerful version of one of the main components of the Eclipse Platform. But while p2 was more or less a complete rewrite, the key with b3 idea is to build upon the exisiting technologies like the PDE build core, Buckminster, EMF and P2. Important key aspects are extensibility and customizability. as well as interoperability with other build tools such as ant and maven.
It is refreshing to see the build process getting more attention as of late, and that the Eclipse community itself is stepping up to the task of making sure that Eclipse based applications are built in a simple, repeatable and reproducible manner.
While Eclipse is certainly one of the defacto industry standards, another one is maven. Just as Eclipse is more than an IDE, maven is more than a build tool. The Tycho project is the maven implementation for building Eclipse plugins. While there are currently maven plugins out there capable of building “plain” OSGi bundles, Eclipse plugins are quite a lot more involved. Since both the maven pom.xml and the OSGi manifest include dependency information, there is a bit of redundancy here. The idea is here to have one of these be the “master” version, and then synthesize the other one from that. This means that projects can either be “pom-first” or “manifest-first” depending on the sepcific requirements and project setup.
There a certainly some roadblocks in the way. For example, both OSGi and maven have a concept of versions that is important for resolving dependencies. And while their format is superficially the same, their notion of version ordering is subtly but definitely incompatible. This can lead to all kinds of havoc.
Hopefully issues like these will be resolved sooner rather than later. Eclipse is not an island. Many applications based on Eclipse RCP are actual rich clients, which means they are connected to a server. These server components are usually more traditional “read: non-OSGI” Java applications, and thus tend to be built by a maven setup. In cases like these it would be desirable to have client and server share the same build infrastructure. This would be a huge boon to many real-life projects out there.
Both these projects show an encouraging amount of progress, and I am convinced that these efforts will go a long way in making the Eclipse and the Java Platform an even better combination. While I think friendly competition is a good thing, competitive cooperation can be even better. Maybe these two projects have slightly different goals and will fill slightly different niches in the future. But I believe there is a lot of common ground, and I hope there is some healthy cross-pollination between these two projects, if not more. Both teams have a quite a background in their respective areas, and thus could bring a lot to the table.
I for one am looking forward to see these two project bear fruit, making the Eclipse build process a lot less painful and a lot more powerful.
I always want to hear why people pick the Eclipse Rich Ajax Platform (RAP) and what applications they are building with it. Last week I send a few questions to Robert Enyedi, CEO at Numiton.com, to find out how they use RAP.
(click picture to view demo)
Elias: What does your application do?
Robert: We are in the business of automated software migration and we wanted to show a bit of what we do. Any visitor can use this tool to browse migration samples shared by others. Registered users can also create their own snippets and share them if they choose to. We currently support the PHP language as input and produce Java code using the Spring framework or just plain servlets. In the future we plan to extend support to other input and output languages from our development pipeline.
Elias: Why did you choose Eclipse RAP?
Robert: The migration system is written in Java on top the the Eclipse RCP framework. So we needed a UI technology that interoperates well with Java.
Also, it had to be a Web application and not a regular site. Rich user experience was a must which brought AJAX-based technologies into focus. We are Java junkies, but an applet or Java Web Start application were out of the question: we couldn’t justify the need for a client-side JRE and its slow startup time for such a relatively simple application. Yes, since JRE 1.6.0 update 10 things improved, but how many users have that version installed?
Having previous experience with the Google Web Toolkit (GWT), that was our next choice. However, as we laid out the features we wanted, we started to see that it will take a lot of effort to implement them in GWT. We wanted readily available functionality like wizards, message dialogs, dockable views and so on. When evaluating RAP we found all these and much more. We quickly rebuilt the prototype with RAP and SWTDesigner and never looked back.
Elias: How did RAP work out in your project?
Robert: We had a fast development time and we found no technical problems that we couldn’t overcome. It is fair to point out though that we have extensive Eclipse RCP experience from building our migration system and not only.
I want to emphasize that personally I am very pleased about the code quality we managed to maintain, even in the final phases of development. Compared to traditional Web applications, developing on the RAP platform makes it easy to produce well organized code. GUI design tools that work with SWT usually work with RWT as well – so designing the perspectives, views, dialogs and composites is very easy.
From the feedback that we have gathered so far, the users love the application and the overall usability is very good. They also appreciate the coolness factor, even if this is a really simple front-end.
Overall we look forward to the e4 platform for which RAP should provide the Web runtime and we strongly believe that even now RAP is the best technology for developing enterprise-grade Web applications.
Elias: Robert, thanks for the interview.
Would you like to share your own RAP story? Email us!
I recently blogged about the OSGi EventAdmin service and got some good feedback. I like to inform people of some more things that came to light about EventAdmin. First, I added a template in PDE for the OSGi EventAdmin service that will make its debut in Eclipse 3.6 M3:
It basically uses OSGi Declarative Services to register an EventHandler that listens for the bundle started event topic by default:
org/osgi/framework/BundleEvent/STARTED
Hopefully this should make it easier for people to get started with OSGi EventAdmin.
Second, Scott Lewis from the Eclipse Communications Framework (ECF) team has a distributed version of the OSGi EventAdmin service implemented. If you want to get at the code, check out the ECF wiki.
Finally, the Eclipse e4 project (the next generation of the Eclipse platform) is somewhat interested in the OSGi EventAdmin service. There’s been discussion on a bug around the general problem of model eventing and how to avoid the ‘listener hell’ problem we had with the old platform.
Only 4 days until the final Galileo SR1 bits are going to be released on Friday, time to write about some good news:
First of all, there is bug 281501 “64 bit Cocoa EPP packages should be available” which is currently the most wanted bug at Eclipse. I never thought that I would ever be the one who owns the bug with the highest number of votes, but finally it is solved and 64-bit Cocoa packages will be available with Galileo SR1. If you have a Mac and if you are able to run these packages, download one of the 20090920-1025 builds, test it and report on the above bug. I would be thankful for additional testing because I am lacking the possibility to test on this platform.
Another great achievement is the ability to upgrade the packages with the help of p2. This morning I tested to upgrade several Galileo packages to the new service release and it worked very well! Look at the About Dialog of the RCP package before the upgrade – I started with a pristine download from eclipse.org/downloads:
Then I had to modify the URLs of the p2 repositories in Window > Preferences > Install/Update > Available Software Sites – see the screenshot below. Note that this step is only required until the final bits are released, because they are only available from a temporary location at the moment. After the release nobody has to change anything here, especially the EPP repository URL is only temporary for build 241.
The last step is the update itself (Help > Check for Updates). This takes some time, but at the end I could restart my Eclipse RCP package and it started with the new Galileo SR1 version:
I am happy to see this working!
Milestone 2 for Eclipse 3.6 is now available. Now that summer is over, and most people have returned from vacation, Eclipse development is starting to ramp up again. Interested in getting involved, now is a GREAT time.
M2 is available from:
http://download.eclipse.org/eclipse/downloads/drops/S-3.6M2-200909170100/index.php
Inside Eclipse, you can use p2 to update with this URL:
http://download.eclipse.org/eclipse/updates/3.6milestones
Finally the new and noteworthy can be read at:
http://download.eclipse.org/eclipse/downloads/drops/S-3.6M2-200909170100/eclipse-news-M2.html
Checkout the great new features like the API usage scans.
The refactoring support in Eclipse has always amazed me. Not only is there a refactoring for just about everything, many of the different Eclipse tools hook into the refactoring support. Frankly, I’ve come to take this all for granted. That is, until earlier this week.
As part of our contribution of the Toast example code from the upcoming OSGi and Equinox book to the Eclipse Examples project, I had to rename the bundles and packages and extensions and DS components and… for 81 bundles and features. Yikes! In the end it took me about 2 hours and both the client and the server just worked. What’s more, I did not change a single file in an editor by hand. Turning on all the replace options finds references in all files.
Old hat for many. Hidden power for some. For me, just using a tiny fraction of the time saved by the refactoring support to say Thanks to all the teams that contribute refactoring participants.
In the past I have said some unkind words about about maven’s pom.xml format. My aversion to xml heavy configuration has drawn me to more lightweight approaches to build systems, like gradle for example. At the same I was intrigued: If a tool like maven is seeing such a widespread use despite its cumbersome format, there must something to make up for it. My curiosity finally got the better of me and I decided to give it a shot. I figured there might be some tooling available to help ease the pain.
And lo and behold, there’s not one but two eclipse projects for integrating maven. One is the IAM project (formerly known as Q4E) and the second is m2eclipse. In that regard it’s a bit like subversive/subclipse but hopefully without all that licensing nonsense. But it is usually good to have some choice – and competition of course. To get a clearer picture I decided to give both plugins a try.
I started with IAM. Setting up my sample project was a snap, and the maven integration immediately started downloading dependencies and adding them to the project classpath. Maven repositories can also hold source jars, making development and debugging much easier. The pom editor seems to cover all options and is looking quite solid. I was more interested in the core feature set, so I didn’t check out any advanced options.
Next up I tested m2eclipse, which offers basically the same core feature set. Dependencies are automatically downloaded and added to the project classpath. The pom editor covered the same functionality as IAM’s, but I personally liked the the looks and layout better in m2eclipse. One really nice feature is code completion for dependencies.
Code completion - rocks!
I know I am spoiled eclipse developer, and I expect my IDE to finish my thoughts for me. But it gets even better: There is also a quickfix (Ctrl+1) for unresolved imports. Talk about convenience!
Quickfix to the rescue!
It’s good to see that there at least two very viable options when it comes to developing maven projects in eclipse. Kudos to both the IAM and the m2eclipse team for the fantastic work.
To me, one of the greatest strengths of the Java Platform has been its rich ecosystem. There are so many java libraries and frameworks out there, that when developing for the Java platform you almost never have to start from scratch. Most of the time it’s finding the right libraries, writing a little adapter code and the core business logic. No need for reinventing wheels. This truly is modular and reusable software development, and one of the main reasons why the Java platform is so competitive.
But this modularity does come at a price known as dependency hell. Any non-trivial project has a dozens of dependencies. Even your basic run-of-the mill webapp requires a web framework, logging, OR mapper, JDBC drivers, etc. Add in all the indirect dependencies and you are looking at quite a lot of libraries. This is why strong dependency management is such a compelling argument for build systems like maven.
But there is another issue apart from painfully assembled builds: Jumpstarting new developers. Especially for open source projects it is quite a turnoff for a potential contributor to look at the long list of requirements and dependencies needed to get to the point where the code even compiles cleanly. This is where strong dependency management comes to the rescue. Sure, maven may download two and a half internets on the first compile, but when its done you have everything ready to start working.
Due to popularity and pervasiveness of maven, there are plugins for integrating almost all imaginable build tools. For most of projects maven provides everything needed right out of the box: unni testing, coverage, javadoc, pmd, you name it. Combined with hudson this makes it ridiculously easy to get a continuous integration server running literally within minutes.
It is good to see that automatic dependency management is making such inroads in different areas of computing. Apt-get and maven, and even p2 have helped a lot to make the dependency hell a little more bearable.
I recently had a few people come to me to chat about the OSGi EventAdmin service. For those who are curious, the EventAdmin service is part of the OSGi Compendium Specification and allows you to publish and listen to events via a pub-sub system. I’ll try to do a quick write up on how to actually use the service. As with any OSGi service, the first and foremost thing you need to do is acquire the EventAdmin service. There are many ways to do this, but I prefer to use Declarative Services these days. This is what a sample component definition would look like:
<?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="org.eclipse.example"> <implementation class= "org.eclipse.example.MyClass"/> <reference bind="setEventAdmin" interface="org.osgi.service.event.EventAdmin"/> </scr:component>
Once we acquire the EventAdmin service, there are really two things you can do: publish and listen for events.
Publishing Events
To publish events, you need to pick a name for your topic. For example purposes, let’s pretend we wanted to publish information about memory events. A good topic name for this would be something like:
org/eclipse/equinox/events/MemoryEvent/{NORMAL,SERIOUS,CRITICAL}
If we wanted to publish a critical memory event, we have to create an Event object and publish it using EventAdmin:
... Event event = new Event("org/eclipse/equinox/events/MemoryEvent/CRITICAL", null); eventAdmin.postEvent(event);
It’s important to note that there are two ways of sending events using EventAdmin. This depends whether you want your event to be sent in a asynchronous our synchronous fashion. In the example above, we used the postEvent(...) method in EventAdmin which sends events in an asynchronous fashion. To send events in a synchronous fashion, EventAdmin exposes the sendEvent(...) method so we could simply change our code to send event synchronously:
... Event event = new Event("org/eclipse/equinox/events/MemoryEvent/CRITICAL", null); eventAdmin.sendEvent(event);
An additional thing to note is that you can send additional properties with your events as the Event object takes an optional Map parameter in its constructor.
Listening for Events
From the consumer side of things, we’re interested in handling the memory events. To do this, we need to register an EventHandler, let’s call it a MemoryEventHandler in this case:
public class MemoryEventHandler implements EventHandler { public void handleEvent(Event event) { // TODO panic... handle memory event } }
Next, we need to register our MemoryEventHandler with the service registry with the proper EventAdmin topic name. There are many ways to do this, but for the variety purposes, let’s do it the traditional way in a bundle activator via a BundleContext reference:
... EventHandler handler = new MemoryEventHandler(); properties = new Hashtable<String, String>(); properties( EventConstants.EVENT_TOPIC, "org/eclipse/equinox/events/MemoryEvent/CRITICAL"); context.registerService(EventHandler.class.getName(), handler, properties);
The important part of the service registration involves topic you’re interested via the EventConstants.EVENT_TOPIC constant. In the example above, we were interested in critical memory events so we used the proper topic:
org/eclipse/equinox/events/MemoryEvent/CRITICAL
If we were interested in all memory events, EventAdmin supports wildcard matching on topics so we could do this:
org/eclipse/equinox/events/MemoryEvent/*
EventAdmin also supports filtering via the EventConstants.EVENT_FILTER constant.
For the curious, the example above could have easily been done using DS:
<?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="org.eclipse.example.memoryHandler"> <implementation class="org.eclipse.example.MemoryEventHandler"/> <service> <provide interface="org.osgi.service.event.EventHandler"/> </service> <property name=”event.topics” value=”org/eclipse/equinox/events/MemoryEvent/CRITICAL” /> </scr:component>
That’s all it takes to listen for events!
EventAdmin in Eclipse
Cool, now that you know more about EventAdmin… how about using it in your Eclipse RCP applications? Well, I have good news as Equinox has a great implementation of EventAdmin available. Furthermore, as of Eclipse 3.6 M2, EventAdmin will ship part of the Eclipse SDK. If you’re not building on top of Eclipse 3.6 yet, you can simply grab the event admin implementation from the Equinox SDK downloads page.
Note: The example I described in this blog is something someone proposed be included within Eclipse.
(18) (4) (120) (57) (8) (54) (119) (35) (8) (10) (17) (10) (12) (7) (14) (3) (20) (5)