I attended the Genuitec Reception last night at EclipseCon where they unveiled and demonstrated the integration of Matisse with their MyEclipse product. It’s a pretty cool addition to their product. Tim Boudreau, NetBeans evangelist, was in attendance and even spoke about Sun’s reaction to the integration (they were initially shocked/surprised, but very quickly decided it was pretty cool).

Tim seems nice. I could take him .

I only managed to catch a few minutes of the Halo Challenge yesterday at EclipseCon. When I left, Doug was taking on seven challengers and was beating them handily (all the while yelling, “I’m in the bunker, no… the other bunker!”).

Janet, Bjorn, and I made a poster describing the Eclipse legal process. It’s pretty complex.Janet printed up a 3′x4′ poster for the exhibit hall at EclipseCon. It looks a lot cooler in “freakin’ huge” size…

Yesterday, I spoke with dozens of folks doing great things with Eclipse technology. One pretty common theme–one that I’ve seen repeated in far too many places–is hesitation to report bugs. Everybody gives a different reason for not reporting bugs. Some simply don’t know how. Some figure that their bugs will be ignored. Some folks actually believe that they’re not qualified to report bugs. There are other reasons; many other reasons.

The mechanics of reporting a bug is pretty easy. All bugs are reported and managed through Bugzilla (you can get here by clicking the “Bugs” link on the home page). Before you create a bug, you should probably determine if the problem you’re seeing has already been reported. If it has already been reported, you should add comments (assuming you have additional information that might be helpful). In order to create a bug (or add comments to an existing bug), you need to create a Bugzilla account. Pretty extensive help is on the Eclipse Bugzilla site.

The Eclipse project teams thrive on bugs. Erich and John spent a good chunk of their talk at EclipseCon today talking about bugs and how valuable they are to the project teams. This is how the teams communicate with each other and the community. It is part of the fabric that is Eclipse to take bugs very seriously. Erich presented an interesting statistic early in his talk: apparently on average every developer on the Eclipse project resolves one bug report every day. John pointed out that the statistic includes more than just bugs: it includes feature requests (he then lamented that Bugzilla doesn’t do a great job of distinguishing between feature requests and bugs). That’s a staggering number of bugs and a great indicator of how important these bugs are to the projects.

Is every bug that’s reported resolved to the satisfaction of the reporter? No. But they’re all looked at and (typically) commented on. Well thought out bug reports that fit well within the spirit of the project, describe the problem well, and provide enough information to consistently repeat the bug are more likely to be resolved. Code contributions in the form of test cases, patches, or additions also go a long way. In short, good bug reports are well-received.

And… we have additional motivation for you. With each milestone release of a Callisto project, we’re giving away stuff to submitters of good bug reports. If you submit a good bug report, you get a “I made Callisto a better place” t-shirt. One lucky bug submitter with each release gets an iPod. And one even luckier submitter gets an Eclipse mountain bike when Callisto is released.

The catch is that you have to submit a great bug report. But don’t worry about making a great bug report (as judged by the project’s developers and, ultimately, the PMC). Just try to make a good bug report. Greatness will follow.

Kim tells me that she added a little something special to today’s Eclipse integration build. The splash screen features none other than SWT’s own Steve Northover posing with the nice models that NetBeans is sponsoring for the week (or the last couple of days anyway). See for yourself… it’s in the CVS repository. Even better, you can download it and try and find a great bug to submit for the Callisto Great Bugs Contest.

For the lazier amoung us, here’s a copy…

Enjoy!

I suggested earlier that I hadn’t yet seen any girls with love in their eyes or flowers in their hair. It turns out, I just missed ‘em (okay, so there were no flowers and more of a vacuous look, but I’ll take it).

The BoF sign up board has arrived and is in the Registration area. If you’d like to host a BoF, there are forms attached to the board for you to fill out (you only need to fill out the front of the form, the back is just the result of a bonehead printing error). Feel free to suggest a time for your BoF and I’ll do my best to respect it (also let me know if you have any other constraints). Ultimately however, I may have to schedule your BoF at a different time.

If you’re interested in attending a BoF, please add your name to the bottom of the form (I see that Doug is optimistic that he’ll need more space than I’ve provided for names). This is important because it will influence where (and to some extend when) I’ll schedule the BoF.

I’ve posted a “preview” of the BoF schedule on the board. Don’t bother scribbling on this as I’m just going to replace this form at (or around) 1700h (5pm) each day (and, while I will try to honor any suggestions you make, I may not be able to). This preview is subject to change, so be sure to check back sometime after 1700h to make sure you’re going to the right place.

If you’re not at EclipseCon… that’s really too bad. You’re missing out on a lot of fun.

I’ve been in California for almost a whole day now, and I have yet to see a girl with love in her eyes and flowers in her hair…

I spent my morning today dropping into the various tutorials to see how folks were doing and helping out where I could. There’s a lot of cool stuff going on. I spent a few minutes working with some folks in the “Extending the Web Tools Platform” (part I) tutorial. It became clear to me that a lot folks really don’t get the Eclipse plug-in model and a real problem resolving some dependency issues. I think I helped out some of these folks; at least I hope I did.

I also stopped in and sat with some folks doing the “Designing Eclipse APIs” tutorial which uses an implementation of tutle graphics. I got there just as the real fun was starting; the tutorial asked that participants use the provided turtle graphics code to draw a house. In the process of trying, they came to realize that the assumptions they made as users differed from the assumptions of the developers. I hope that they understand the subtle brilliance of the exercise (I’ll have to check back later).

I dropped in a few other tutorials, and it seems that everybody is getting a lot of value out of them. I’m going to poke around some more after lunch.

I’m getting read to fly out to Santa Clara on Sunday for EclipseCon 2006. This will actually be my first EclipseCon. I never did get a chance to attend in my previous job, but now that I’m the Eclipse Evangelist, attending comes as part of the job. I’ve attended dozens of conferences before, but I have to say that I’m way more excited about this one than any other conference I can remember. Really.

Bjorn and I chatted a few days ago about some conference things that are important to us. One of the things that we both decided feels like a tiny detail, but is really important is the readability of name badges. Bjorn informed me that names should be really easy to read as they’re (apparently) using the largest font size available. This means that I’ll be really easy to find: just seek out the loudest and most obnoxious thing in the room, and confirm that he’s wearing a badge with my name on it. If you can’t see the badge, I’m the one who looks like a young Pierce Brosnan.

There’s lots of good reasons to hunt me down at EclipseCon. To start, I want to talk with you about all the exciting stuff you’re doing with Eclipse. I speak at lots of conferences, user groups, and company picnics (I’m still working on the last one) and having great real-life stories about Eclipse to relate to folks goes a long way.

More pragmatically, however, you’ll want to talk to me if you want to host a BoF session. Yessir, Bjorn foolishly gave me power. And I intend to use it. More seriously, if you do want to host a BoF, there’ll be sign up forms at the conference. Find a form, fill it in, and post it on the sign-up board. If you’re interested in attending a BoF, make sure that you review the sign-up board and put your name down. I’ll be basing room assignments on the number of folks who intend to attend.

You’re welcome to try, but I can’t be bribed with beer. See you at the conference.

Last week, I blogged about some work that I’m doing with Eclipse Monkey. I finally found a few minutes to wrap it all up into an RCP application. In doing so, I did have to refactor the Eclipse Monkey code a bit. These changes are focused primarily on extracting the runtime elements of Eclipse Monkey from the ide parts (my RCP application doesn’t need a “Monkey” menu, for example). I’m wrapping up the refactoring so that I can contribute the changes back.

The scripting part is pretty easy, but leans heavily on having a good set of DOMs to actually do the heavy lifting. Fortunately, building good DOMs has thus far been pretty easy; I’m not sure that I’m ready to start building an enterprise-scale application with the technology (though, I’m not aware of anything in the technology that is limiting), but it seems to be pretty powerful for quickly cobbling together an RCP-based mashup. This will only get easier as more and more useful DOMs are created.

To build the RCP application, I created a new plug-in to represent the application. I modified the perspective to include placeholders for the views (thereby indicating where each of the views should be positioned), and added a postUpdate() method to the WorkbenchAdvisor that invokes the script. Here’s the result:

I still have lots of work to do before this is really useful. I need to, for example, build a DOM that provides a decent way of prompting the user for information (the flickr browser so far hard-codes the search pattern in the JavaScript). I thought of using a view for this, but it feels “clunky”; I’ll probably just create a “common dialogs” DOM that includes a text prompter (or something like that). I’m also going to generalize the “image view” DOM to support multiple instances and more arbitrary image sources.