Some of you may have seen Yoxos 5 at EclipseCon 2011.  For those who aren’t familiar with it, Yoxos 5 is a tool that enables the creation of a profile that describes your Eclipse installation. Another developer can start the same Eclipse installation by clicking on a .yoxos file. Yoxos will download and install all necessary plugins, set the preferences, connect to the source code repository and even show you the tasks from your bug tracker. These items are continuously updated with changes.  For example,  if you add a new plugin to your daily development environment, all team members will automatically get an update. Ian’s talk at EclipseCon 2011 showed how this can be used to get developers working on an open-source project quickly, e.g. for a “bugday”. The full team service is freely available for open-source projects.

In the latest release, we’ve added another much-requested feature:  the provisioning of target platform definitions. The basic idea is that you can provision target platform definitions with Yoxos and set one target platform to activate by default. The target platform itself can be on an update site, in your workspace or anywhere else. Using a local folder or an Eclipse installation may not make too much sense, unless these sources can be downloaded by other users. You can configure the target definition in the normal way, using the PDE UI. Once you have added it to your profile, it can be used by all developers on the team.

You can activate Target Provisioning in the launcher from the tab “Workspace Provisioning”

Then,  you’ll see a new tab in the application:

Once you have set your target platform definitions, you can import them from your IDE into a profile (via the magnet button).

By checking one of the target definitions in the table, you’ve set the default that will be activated on start-up of the installation.

Note that you should remove the target platform definition file from plugins that are provisioned by the team provider. Otherwise you will get the the same target platform twice, once provisioned by the SCM, once provisioned by Yoxos. The Yoxos provisioned target definition always has a postfix “provisioned by Yoxos” to distinguish them. In general, moving the target definition out of your workspace might be good practice, as changes to the target platform can then be managed by the same person who configures the Yoxos profile.

You can give Yoxos 5 a test drive – visit http://eclipsesource.com/yoxos5. Let us know what you think about Yoxos and target provisioning.

Tags: platform, provisioning, target, yoxos

One of the new things in RAP 1.4 is the FileUpload widget in RWT, that replaces the old Upload widget from the sandbox. And there’s some more new upload stuff in the RAP Incubator. Here’s how to use the new features to upload files with RAP 1.4.

The FileUpload is a new widget that wraps the HTML file selection <input> tag. It looks like a button, and when it’s pressed, a native file dialog opens up that lets users select a file from their local file system. On file selection, a SelectionEvent will be fired. You can then programmatically upload the selected file to an http server using FileUpload.submit( URL ).

In order to receive and store the uploaded files on the server, you also need a server-side component. We created such an upload server component in the RAP Incubator. It’s called FileUploadHandler and it uses the Apache fileupload component internally. It’s included in the bundle org.eclipse.rap.rwt.supplemental.fileupload. This handler accepts file uploads to a certain URL (FileUploadHandler.getUploadUrl()) and delegates the data to a FileUploadReceiver. You can either use the provided DiskFileUploadReceiver or create your own receiver to do whatever you like with the uploaded data: put it into a database, or simple analyze the data and discard it.

Sounds complicated? Well, there’s a much easier way to upload files with RAP 1.4! We’ve encapsulated the entire upload process in an implementation of the SWT FileDialog, which is also available in the incubator.

To make it easy to use, we now provide an update site for the Incubator. To use the FileDialog in your application, all you have to do is to:

1. include the bundles from the RAP Incubator repository http://download.eclipse.org/rt/rap/1.4/incubator/ in your RAP 1.4 target platform, and
2. add a bundle dependency to org.eclipse.rap.rwt.supplemental.filedialog to your project (yes, you have to use Require-Bundle here because this bundle contributes a class to the org.eclipse.swt.widgets package, effectively creating a split-package).

That’s all. Now you can use the FileDialog just like in SWT:

  FileDialog fileDialog = new FileDialog( shell, SWT.TITLE | SWT.MULTI );
  fileDialog.setText( "Upload Files" );?
  fileDialog.setAutoUpload( true ); // This API will change, see below!
  fileDialog.open();
  String[] fileNames = fileDialog.getFileNames();

After uploading, the dialog closes and the variable fileNames contains the absolute file names of the uploaded files on the server’s file system. There’s an auto-upload feature that is really nice (I think it should be the default) – with autoUpload on, the upload starts immediately after file selection. A user can still press Cancel to prevent the application from using the uploaded files.

Note: Please note that this stuff is in the incubator and not part of the 1.4 release. The API and implementation may (and will) have to change and mature over time. However, if you use the latest version from 1.4/incubator site, you’ll always get a file dialog that will work with RAP 1.4. The server-side upload receiver and the required Apache bundles are also included.

We hope you enjoy these new features. Please try them out, tell us what you think, open bugs for the new stuff, and help us improving them.

Kudos to our new RAP committers Austin Riddle and Cole Markham who created this great new feature!

Update: I mistakenly left out the “.rwt.” from the bundle namespace in the original post, the bundle names are fixed now in the text.

Update: The 1.4 incubator repository has been updated with a newer version of the file dialog that is compatible with RAP 1.4. This update fixes the problem with missing file names mentioned in the comments.

Tags: indigo, new and noteworthy, rap, Single Sourcing

The Eclipse Packaging Project defines pre-configured Eclipse distributions.  If you are develop in C/C++ there’s a package for that. If you need to create RCP applications there’s a package for that. Using p2 or the Eclipse Market Place you can customize your install until your heart’s content.

However, each time you download a new package, you’re most likely downloading the same 80-90M.  You are downloading SWT, JFace and maybe even the JDT over, and over and over again.  These Eclipse installs begin to clutter your machine and remembering which install contains which plug-in becomes practically impossible.  I currently have 17 different Eclipse installs on my machine:

Over the past few months I’ve been working on a solution to this problem, and now you can provision your own tool chain, the way YOU want it, from the cloud — and share all your plug-ins.  All you need to do is download and install the Yoxos Launcher.  When you start Yoxos, you will be prompted to select a pre-configured EPP Package (or you can also select “advanced mode” and create your own package).   You can even share the configurations between team members to help you get up and running faster.

All the artifacts are hosted on Amazon CloudFront, so the download should be pretty quick (I provisioned an entire ‘Eclipse Classic’ in under 5 minutes).  And all your plug-ins are shared between installs, so if you install a second package, Yoxos only downloads the new stuff it needs.

Using the Yoxos Customizer Perspective, you can add new components and craft your own customized Integrated Development Environment. The Yoxos repository holds almost 2,000 components including everything from Indigo.

Finally, you can set your upgrade strategy. That is, you can tell Yoxos that you want to receive all updates as they happen, or you would rather stick to an exact Eclipse version.

So to recap:

• Almost 2,000 components are available
• All the components have been tested to ensure that all required dependencies are available
• All the artifacts are hosted on the Cloud (AWS CloudFront)
• All your plug-ins are bundle-pooled and shared between installs
• You can configure your upgrade strategy
• The service is free, go ahead and try it.

Tags: indigo

As you may know I live on the Canadian west coast (In Victoria British Columbia). We are 3 hours behind Easter Time, which means that the Eclipse release was supposed to happen at 6:00am for me.

I awoke this morning to find this in my inbox:

I would like to challenge you to find another piece of software that has consistently delivered On-Time since 2001.

I would also like to point out that this is no accident.  Eclipse ships because there are very dedicated people working tirelessly behind the scene.  While there is no way I can enumerate all of them, a few special thank-yous are in order. Of course all the committers, project leads, PMC, and council members deserve big thank-you.  There would be nothing to ship without you.  But for a release to ship with such consistency, you need rock solid release plan and outstanding release engineers.  I don’t know all the release engineers personally, but certainly Kim Moir and Nick Boldt have been doing an awesome job for their respective projects.  Markus Knauer gets the shout-out for the great job he does assembling the Eclipse Packages.

Of course, Denis Roy and the entire Eclipse webmaster team deserve the credit for managing the infrastructure behind all of this. I imagine that most software projects would use an excuse like ‘our hardware is on fire‘ to delay the release — not at Eclipse, because remember, ship happens.

But the biggest thank-you goes out to David Williams, whose leadership, (nagging ), and vision has made this entire process possible. Thank-you!

Tags: indigo

After 12 months, 62 projects, 46, 000, 000 lines of code, over 400 committers and 1 Top 10 List: Eclipse Indigo is here (Or use the new Yoxos launcher to install Eclipse from AWS CloudFront).  For the past 10 days I’ve been counting down the 10 most exciting Eclipse Indigo features according to me:

10. Maven and Eclipse
9. Equinox / p2 Improvements
8. PDE Improvements
7. JDT Improvements
6.  Gravatars (and Other Mylyn Improvements)
5. Xtend 2
4. CDT Codan
3. RAP: Bringing Eclipse APIs to Mobile Devices
2. Window Builder

There is a lot of other interesting work happening around Eclipse, such as the Jubula Automated Functional Testing tool, but unfortunately, I haven’t had a chance to work with all this great technology.  I encourage you to try out all these great tools, and if you disagree with my Top 10 List, write your own.

Now, without further ado, my number 1 Eclipse Indigo feature is: EGit/JGit 1.0.

If you haven’t used a distributed version control system — take some time and learn one now.  Distributed version control systems (DVCS), like Git and Mercurial are one of the biggest game changers in software development in the past 10 years and will become the De Facto standard for revision control sometime this decade. GitHub is already dominating the forges, and if you’re a software developer, chances are you will collaborate with someone using a DVCS before the next Eclipse release (which by the way will be called Juno).

EGit is the Eclipse Git project and it’s intended to bring Git tooling to Eclipse.  EGit is built on top of JGit, an implementation of Git in Java.  There are a ton of new features like

Blame Annotations

Staging View

Powerful History View

Commit search and commit explorer (search for past commits)

And my favorite, an Improved Synchronize View

Many of the Eclipse projects will be switching from CVS to Git this year, including the Eclipse SDK.

If you are new to Git, there are several resources available to help you get started. I suggested looking at the book Pro Git, and checkout Alex Blewitt’s Git Tip of the Week. There is also an Eclipse EGit tutorial for beginners.

Thanks to all the EGit / JGit commiters: Chris Aniszczyk, Christian Halstrick, Gunnar Wagenknecht, Mathias Kinzler, Matthias Sohn, Robin Rosenberg, Shawn Pearce, Stefan Lay, Sasa Zivkov, Benjamin Muskalla, Dariusz Luksza, Jens Baumgart, Kevin Sawicki, Mik Kersten, Mykola Nikishov and Remy Suen.

And finally, thank-you to everyone who helped ship Eclipse Indigo on Time and On Budget.  Remember, at Eclipse, Ship Happens.

Tags: indigo

We are one day away from the Eclipse Indigo release, and that means we are into the Top 2 Features On My Eclipse Indigo Top 10 Feature List.  Number 2 on my list has been part of the Eclipse EcoSystem for years, but it’s actually a newcomer on annual release train: Window Builder.

Window Builder is an award winning, bi-directional, Java GUI designer.  The tool supports both Swing and SWT/JFace and is a must-have for anybody designing Graphical User Interfaces in Java.  Not only does the tool allow you to mock-up your UIs, it generates production ready code without any additional run-time dependencies.

The Swing Designer supports JDialogs, JFrames, JPanel, and more.

The SWT Designer supports simple SWT interfaces, JFace dialogs (such as Wizards), Forms, Databinding integration, and support for creating RCP applications.

You can also preview your interface as you develop them:

The bi-directional editing means you can seamlessly move between a Drag n’ Drop designer and the generated code.  Window Builder can be used to get your UI up and running quickly, or to maintain and evolve your UI over the long term.  You can even use window builder on existing UIs — ones that were not originally created with the tool.

Regarded as one of the best GUI design tools available, it’s great to have window builder on this years Eclipse release train.  A special thanks goes out to all the Window Builder committers: Eric Clayberg, Konstantin Scheglov, Alexander Mitin, Andrey Sablin, Jaime Wren, Dan Rubel, Mark Russell, Devon Carew, Rajeev Dayal, Miguel Mendez, David Carlson, Alexander Humesky, Xavier Ducrohet, Raphael Moll, Tor Norbye, Ed Merks, Kenn Hussey, Christian Campo, Neeraj Bhusare, Piotrek Tomiak, and Vadim Ridosh.

Tags: indigo

There is no question that the mobile market is huge and practically growing by the second.  There is some excellent mobile development tools built on top of Eclipse, however, each mobile platform requires Yet Another Language and Yet Another Set of APIs.  Developing an enterprise application with a Web, Android, IPhone and Rich-Client interface requires several dedicated development teams, each one specialized in a different technology stack.  For this reason, most vendors simply choose a subset of platforms to support and hope their clients are too dissatisfied.

The Rich Ajax Platform (RAP) changed all this by supporting a single programming model for both Web and Desktop. With the Eclipse Indigo release, RAP now supports a number of mobile platforms through the mobile browser.  For the past week 1 1/2 weeks I’ve been counting down my top 10 Eclipse Indigo Features and number 3 is: RAP, bringing the Eclipse API to mobile devices.

RAP has nothing to do with putting the Eclipse IDE on the web (or on a mobile platform).  The purpose of RAP is to bring a consistent programming paradigm (language, API and programming model), to a variety of different platforms — this is called single sourcing. With RAP, you can reuse your content providers, JFace viewers, Jobs, Progress Monitors, etc… while targeting the desktop, web, and now, mobile.  Of course, you will likely design a different interaction model for each platform, but the business logic only has to be written once.

In addition to Mobile support, RAP has introduced a number of new features such as a much improved (and long awaited), updated tree widget (Kudos to Tim Buschtöns). The widget supports SWT.VIRTUAL, making it load much faster.  It also supports gridlines, full selection support, item and cell colours / fonts and much more:

There are also a number of theme improvements, so it no longer feels like your “running an IDE in your browser”. Improvements such as drop shadows on a number of widgets, theme-able scroll-bars and gradient backgrounds.

Thanks to everyone on the RAP team for making my life so much easier. Kudos go to: Ivan Furnadjiev, Holger Staudacher, Tim Buschtöns, Ralf Sternberg,  Austin Riddle, Benjamin Muskalla, Frank Appel and Rüdiger Herrmann.

Tags: indigo

Probably one of RAP’s best known features is its single-sourcing capabilities. Some time ago we created a guide on Single-Sourcing RCP and RAP applications. The guide recommended a technique where a facade and fragments were used to invoke the RCP or RAP implementation during runtime. With this post I want to show you how to achieve the same the OSGi way.

For single-sourcing a RAP or RCP application, its straightforward to use the power of OSGi because it’s included in both platforms out-of-the-box. OSGi has a central concept called services which are simply POJOs and are used to allow communication between modules. And, you can register or resolve services at any time in your code.

The basic Idea behind using OSGi services for single-sourcing is as follows. We need to extract all the things that vary into separate, platform specific bundles. To use the different implementations, we have to create an interface in a “common” bundle that contains the methods we want to use. The platform specific bundles have to register an implementation of this interface as a service. In the “common” bundle we can reference the registered services and use them to get the platform specific stuff. More specifically, we register a RAP implementation in a “rap” bundle and an RCP implementation in an “rcp” bundle. The only thing we need to do then is to start the right bundles on the associated platform to get the right service.

With this solution we can extract the platform specific stuff into separate bundles and we don’t have to rely on fragments. So enough talking. Let’s look at some code. I decided to create a very simple single-sourcing interface which can be used to get the WidgetUtil.CUSTOM_VARIANT constant value. This constant exists only in RAP so, it’s a good example for showing how to handle the differences.

public interface ISingleSourcingService {
  String getCustomVariantString();
}

I have created three bundles: one that contains the application which is entitled “com.eclipsesource.app” and one for each platform. These are called “com.eclipsesource.app.rap” and “com.eclipsesource.app.rcp”. Both platform bundles implement the interface.
RAP:

  @Override
  public String getCustomVariantString() {
    return WidgetUtil.CUSTOM_VARIANT;
  }

RCP:

  @Override
  public String getCustomVariantString() {
    // There are no custom variants in RCP
    return "";
  }

And both bundles are registering the service in their Activator during the start method call.

  public void start( BundleContext bundleContext ) throws Exception {
    Activator.context = bundleContext;
    registration = context.registerService( ISingleSourcingService.class.getName(),
                                            new RAPSingelSourcingService(),
                                            null);
  }

When it comes to using the service in the common “app” bundle we can use a ServiceTracker to get the service implementation (you can also use DS).

  private ISingleSourcingService getSingleSourcingService() {
    // We use a tracker to get the service. We also can use DS to get it.
    Bundle bundle = FrameworkUtil.getBundle( getClass() );
    BundleContext context = bundle.getBundleContext();
    ServiceTracker tracker
      = new ServiceTracker( context,
                            ISingleSourcingService.class.getName(),
                            null );
    tracker.open();
    ISingleSourcingService service = tracker.getService();
    tracker.close();
    return service;
  }

The only thing we have to do now is to create two launch configurations which contain the associated platform-specific bundle.

That’s it! You can find the sources in this github repository. Have fun using OSGi services to single-source applications.

Tags: eclipse, GitHub, OSGi, rap, rcp, services, Single Sourcing

The C/C++ Tooling for Eclipse is old Mature! In fact, the first bug report filed against the CDT was opened on January 14th 2002, Only a few months after Eclipse 1.0 shipped.  If my trivia knowledge is correct, the CDT is the oldest Eclipse project (next to the Eclipse IDE itself) and it has grown into a first class C/C++ IDE.

As with all previous release trains, the CDT is on board and ready to ship some awesome new features.  As we approach yet another Eclipse release, I’ve been counting down my top 10 favorite features.  The C/C++ Code Analysis is number 4 on my list.

C++ is hard to parse!  And when languages are hard to parse, it’s very hard to develop solid tool support for them.  In many cases. parsing the language requires a full compile step which would not be feasible for the type of real-time feedback expected by developers.  (During my Master’s degree (2001) we ripped the front end off of GCC to create a C++ fact extractor called CPPX [ref, ref], but incremental updates still required a full re-run of the tool, not acceptable if you are looking for errors as you type.)

Now, throw in the fact that C++ accepts input that can result in infinite recursion, and you have a challenge .

Feed this to your favorite C++ parser and see what happens [ref,ref]

template<class T> struct Loop { Loop<T*> operator->(); };
Loop<int> i, j = i->hooray;

Luckily for C++ developers, the Eclipse CDT has leapt past this hurdle and produced a pretty awesome Code Analysis tool, (Codan) which is no easy feat!  This tool will now reveal many static analysis problems while you type.

This opens up the door for many advanced IDE features such as quick fixes, detection of unused functions, suspicious semicolons and more.

Kudos to this work goes out to Alena Laskavaia with help from Sergey Prigogin .

In addition to Codan, there are a number of exciting new features in the CDT this year.  A really cool feature is project-less debugging. This allows you to use the CDT for debugging without actually using the tool for your development.  This type of feature will greatly help adoption as it lowers the barrier to entry.

For a complete list of New and Noteworthy features in the CDT, checkout their wiki page.

A big thank-you for all this work goes out to Doug Schaefer, the CDT team lead and the rest of the CDT team:

James Blackburn, Patrick Chuong, John Cortell, David Dubrow, Emanuel Graf, Andrew Gvozdev, Mikhail Khodjaiants, Marc Khouzam, Vivian Kong, Mike Kucera, Marc-Andre Laperle, Alena Laskavaia, Toni Leherbauer, Teodor Madan, Pawel Piech, Sergey Prigogin, Chris Recoskie, Randy Rohrbach, Ken Ryall, Markus Schorn, Ed Swartz and Ling Wang.  Great work everyone!

Tags: indigo

The Eclipse Indigo release is now less than 1 week away, which means I’m into the Top 5 Entries in my Eclipse Indigo Top 10 List.  Number 5 on my Top 10 List is near and dear to my heart as I started using some of this technology 5 years ago when it was hosted at openArchitectureWare.  In fact, I spent 5 1/2 years of my life studying Model Driven Development, and I find the entire Model-2-Text and Text-2-Model fascinating.

Number 5 on my Top 10 Indigo Feature List is Xtend 2. Xtend 2 (part of the Xtext project) is a code generation language compiled to performant Java code.  The language supports a number of constructs such as:

• Both static and injected dynamic extensions
• Closures
• Polymorphic method dispatching
• Smart string processing
• Type inference
• and more…

But the best way to demonstrate this is through a real example.  Let’s assume we get tired of writing Top 10 Lists and we simply want to specify the elements and have the blogs write themselves. We could use the smart string processing of Xtend 2 to describe the Model-2-Text transformation

While this particular example would simply output text, we could enhance the transformation to write out HTML, XML, DocBook, LaTeX, etc…  From here, we could use Xtext to describe a Top 10 List Grammar:

Xtext now has a graphical view of the grammar

There are also a new quick fix options available, refactoring support and a content assist improvements.

Once we have our grammar, we can now use the generated language (and generated tool support) to create our top 10 list

Finally we can call the generator to create the textual representation of the post:

Sven Efftinge is the master mind of the whole X family (according to Peter Friese).  Kudos also go out to Sebastian Zarnekow, Jan Köhnlein, Holger Schill, Moritz Eysholdt and Dennis Huebner.

Tags: indigo