Chris Aniszczyk's (zx) diatribe

I’m a fan of the Eclipse Marketplace.

It’s easy to install solutions from within Eclipse (Help -> Eclipse Marketplace…), for example, if you need Git support… simply use ‘git’ as a search term…

If you’re an Eclipse.org project, I highly recommend listing a release of your project if you want to make it easier for users to find your work. I’m a lazy user so anything that can be done to not have to enter a URL is a plus in my humble opinion.

So what’s missing? Well, I would like to see the marketplace work with other Eclipse plug-in distributors out there. I know that the marketplace supports pluggable marketplace providers as the folks at EclipseSource are taking advantage of this functionality via the Yoxos Market. However, I’m more looking at the folks within the IBM Lotus community who are doing cool things by having plug-ins for Symphony available via the web. I think both communities would benefit by having more cross-pollination with the plug-ins that would work in both environments. On top of that, I would like to see “appstore” like functionality at the marketplace in the future so people could offer their wares for sale if they wanted to. I know this isn’t easy due to the complications of selling goods in various countries and the tax laws that accompany that but we could start with a few pilot countries.

In the end, I think the marketplace makes it a lot easier to find Eclipse-related stuff and opens a lot of possibilities to make Eclipse more consumable for folks.

Shawn Pearce and I are giving a webinar on July 13th about Understanding and Using Git at Eclipse…

The EGit project is implementing Eclipse tooling on top of JGit, the Java implementation of Git. Both EGit and JGit moved to Eclipse in May 2009 and shipped 0.8 with Helios. The EGit and JGit teams are busily working towards 0.9 which is targeted for Helios SR1 (September 2010). This webinar will give an update on the project progress and more detailed information about the design and features. A demo will illustrate how it’s used in its own development process. It will also show how Gerrit Code Review, a JGit based review system developed for the needs of the Android community, can help to further improve development processes.

Please register if you want to attend and learn more about Git and Eclipse.

On a side note, there will be a free GitTogether event October 25-27th at Google HQ. Git contributors and users alike are welcome to attend. If you’re interested in Git and in the bay area, please consider attending.

Yesterday, we held the Eclipse Toronto DemoCamp at the Red Hat Canada offices.

Thirty or so people showed up and there was a lot of good presentations..

1. Elliott Baron, Path-Sensitive Static Analysis for C/C++
2. John Bossons, Wizards to make JPA value objects thread-safe
3. Jason van Zyl, m2eclipse and tycho
4. Chris Aniszczyk, Understanding and Using Git at Eclipse
5. Ian Bull, Managing your eclipse installs
6. Kenn Hussey, b3 Aggregator
7. Charley Wang, C/C++ function call visualizations
8. Andrew Overholt, Eclipse Linux Tools project

I talked about Git and demoed EGit a bit…

Afterwards, we headed to the Rose and Crown pub for drinks and food!

Overall, it was fun and thank you Eclipse Foundation for sponsoring the event!

Maybe I’ve been under a rock as of late, but I’ve been writing some tests as of late and came across a nifty little feature in JUnit4 called Rules while needing to verify a certain exception was being thrown. For example, let’s say we needed to verify that something threw an IAE…

public class MyTest {
  @Rule
  public ExpectedException exception = ExpectedException.none();
 
  @Test
  public void willThrowIAE() {
    exception.expect(IllegalArgumentException.class);
    exception.expectMessage("omg bad arguments");
    // do crap that will throw an IAE
  }
}

This is just the tip of the iceberg with what you can do with rules. There’s also a rule (TemporaryFolder) for creating temporary folders that are guaranteed to be deleted after the test is run. On top of that, it’s pretty easy to create your own rules if you need to modify test behavior to suit your needs.

In the end, it’s always fun to discover something new and useful in a tool you’ve been using for awhile.

Yesterday, Ian Skerrett posted some links about Helios in the press.

During my morning coffee ritual I read through most of them… I was especially taken with Dana Blankenhorn’s article…

This was always a false image. Not that I have anything against a good parent’s basement, or a nice comfortable pair of jammies. And when open source was being born, at the bottom of the dot-bomb, there was high unemployment in the code-o-sphere.

But the coders and the coding were always professional. There have always been a lot of people in open source who knew how to make the coding train run on time.

So with Eclipse’ Helios dropping yesterday, right on schedule (even with everyone else watching the U.S.-Algeria game) it’s worth noting that this is the seventh straight year that the code has arrived on precisely the day it was supposed to.

Eclipse is the open source dog that does not bark. Its professionalism is the clue that unravels the whole case, and makes much else possible. Many things go wrong in our troubled world, but professionalism like this can get us through.

Ruff? Arf? Anyways, something to be proud of in my opinion.

Of course there was also some criticism…

The big problem with any Eclipse release if finding out what it’s all about and what you have to do to start using it. As with most open source projects, the documentation is terrible and idiosyncratic. Given time on-line tutorials and third -party documentation, books, howtos,.. will start to catch up with the new release but for the beginner it’s initially an impenetrable wall.

It’s not just basic documentation that is a problem. Finding out what any given Eclipse package or project does can be next to impossible. If you don’t already know what it’s is all about then the only way to find out is to download and experiment. This isn’t helped by the fact that currently the web-based help system seems to have a bug that stops it working. The Eclipse project is often flaky on features used by beginners – it’s probably because the Eclipse developers test the cool interesting stuff and mostly ignore anything trivial.

In addition the whole approach of the Eclipse documentation is to tell you about the development process of the project, how it was started, how many milestones have been kicked over and so on. All very personally satisfying but useless for the beginner who might actually be tempted to use this free IDE.

Adding easy to follow feature descriptions and introductory explanations to the front pages of the web site would probably increase the take up of Eclipse by a factor of 10 or more. Just because it’s open sources doesn’t mean it has to lack commercial acumen.

Ok, that’s fair enough, not every project has nice documentation like Xtext or some other Eclipse projects. However, I think we’re better than most. I’m not sure how we can improve besides having some consistent guidelines projects can follow so regardless of which project you go to, the documentation is presented in a similar fashion. Any ideas?

On Thursday, there will be a virtual conference demoing some of the things part of the Eclipse Helios release.

I’ll be speaking about Git tooling at Eclipse but there will be talks about JavaScript tools, Linux Tools, EclipseRT and other projects. So please sign up if you want to learn more about what is shipping with Helios and remember to tell your friends too!

Since I’m a Friend of Eclipse, I was pleased to see this email today!

So if you want to grab Helios a day early, why not consider supporting Eclipse by becoming a friend! We are almost at 360 Friends for Helios too!

Let’s fill that progress bar!

Last week the EGit and JGit teams pushed out 0.8.4 as the final contribution to the Eclipse Helios release. A few people praised the teams on how quickly progress is coming along which is great. A few people have also asked about what is officially support in EGit versus typical command line usage so here’s a picture to help with that…

A few people have also pinged me about a Maven repository for JGit. You can find information on the repository on our download page.

An important thing to note is that I still consider the 0.8 release a beta (we are still in incubation). If you’re familiar with the Git CLI, the tooling should be pretty easy to pick up. We are planning to do a 0.9 release in late September for Helios SR1 which should contain the last missing pieces needed for mass adoption of Git within the Eclipse community. For now, if you like to live on the bleeding edge please give the 0.8 release a try and report any issues you find.

We now have some wallpaper to decorate our computers to celebrate the Helios release!

Thanks Nathan Gervais!

The past couple days I’ve been in scenic Raleigh, NC for a Eclipse.org board meeting. The committer representatives and I brought a proposal forward to help alleviate some of the problems discussed in bug 313479. The goal is to expand the Friend of Eclipse program and use funds to benefit the entire Eclipse committer and contributor community.

Here’s the exact board resolution…

RESOLVED, the EMO is instructed to expand the Friends of Eclipse (FoE) program to:

a) provide greater community transparency regarding the allocation of funds, consistent with the Bylaws; and
b) consider greater inducements for larger donations.

All donations will be used for the benefit of the entire Eclipse committer and contributor community.

The EMO will create a governance process for transparently allocating the FoE funds.

Stay tuned for details, the expansion should hopefully be implemented in the near future. In the end, the committer representatives hope this helps the Eclipse community and makes people think about becoming a Friend of Eclipse to support Eclipse!