Oisín Hurley's Weblog

I'm in Logan Airport, on my way back to Dublin after a hectic few days in Cambridge at the EclipseWorld 2006 conference. I went over there with a job to do: as the the PMC Lead for the SOA Tools Platform (STP) project, I had a talk to give, updating the attendees with the status of the project. I think it went over pretty well - our presentation (pdf link) was chock-full of details of the STP sub-projects and included a number of demos of the code contributions.

Wayne, I thank you most sincerely and look forward to working with you. I've subscribed you to the stp-dev mailing list too :-)

I got the chance to talk to a number of interested tech journalists and analysts during EclipseWorld and sure enough, the STP got some nice mentions in the tech press:

• Micheal Meehan's piece at SearchWebServices
• Dana Gardner's Blog
• Paul Krill at Infoworld
• Rich Seely's EclipseWorld preview

It's great to get this kind of coverage at this stage. Hopefully it will generate more interest for those developers who might want to use the SOA Tools Platform in the future.

By the way, if you are one of those developers, we would really like to hear from you: if you check out our Call for SOA Scenarios page you will see some of the feedback we have received on typical SOA development scenarios. You can edit this page once you create a wiki account and add those items that are important to your SOA development requirements.

Update:
A clarification - the SOA Tools Platform has not limited itself to Web Services only, but intends to include the tooling elements to support construction of other mechanisms of service creation - for example, a CORBA interface and its servant implementation.

If you look into the SCA Assembly specification, you'll see that the assembly description has extension points for implementation/interface/bindings, so the space is there to be innovative about service creation. As we grow the STP, you'll see approaches for deploying Services that aren't related to WSDL or WS-* standards.

Working in OSS projects means that much of the time the only chance you get to meet co-developers and other community members is when conferences like EclipseWorld happen. Usually, you get to meet brand-new people and have interesting conversations with them.

At the Wednesday night Tailgate Party at EclipseWorld I was introduced to Chris Aniszczyk and - I don't know how we got into it - we had a little conversation about the PDE. My major gripe relating to the PDE is the headless facilities for automating build, test and coverage - after I compared it to something like chewing ground glass, Chris informed me with a grin that he worked on the PDE UI.

The PDE UI you will agree is in good shape. You just have to take a look at the new and noteworthy for 3.3 M1 to see that the team haven't been sitting on their keisters since Callisto. It's great to use, but from my perspective it's only part of the equation of shipping software on the Eclipse platform.

Back to the PDE headless build.

The PDE build works - right now every Eclipse project uses it as far as I know. But it's got a steep learning curve, and it's brittle. I know this from experience :-)

So let's fast forward to now: in STP we got the PDE build to work well under the expert guidance of Naci Dai, who is the JST lead and buildmeister extraordinaire. Adrian carries on the torch and maintains the STP build for us.

I've probably timed this badly, but we would like some more people to help us with build mastery. Send email to the usual address - stp-dev@eclipse.org :-)

Update: looks like Felix is heading out of incubation!
Update: a sudden conversation on Bug 154251 - Maven2 Integration shows some relevant work in progress.

In a previous entry I mentioned SML and the fact that I got a chance to speak with one of the authors at EclipseWorld. During the conversation we were joined by Mark Weitzel and Joel Hawkins and we started talking about something called the COSMOS project - a joint effort between IBM, Cisco, HP, Compuware, IBM, Intel and others. This project was about unifying a lot of the capabilities of SOA Systems Management and agreeing on resource modeling approaches using the aforementioned SML.

Just today, I read an entry on Chris Aniszczyk's blog stating that COSMOS had been proposed as an Eclipse project.

This looks like a good idea to me, and from the point of view of the SOA Tools Platform Project it could make it more straightforward for us to incorporate management of SOA resources.

By the way, Mark and Joel put together a really interesting talk and demo at EclipseWorld in which they managed to mashup SCA, Tuscany, OSGi, and TPTP. I was totally impressed!

An open source 'mastermind' panel was held at the Gartner conference last week. Mike Milinkovich of Eclipse, Brian Behlendorf of Apache and Collabnet and Stuart Cohen of OSDL.

I diligently wrote down all of the conversation until, unused to actually using a non-keyboarded writing instrument, I cramped up :-)

Luckily Zack Urlocker was much more diligent than I, and captured pretty much everything in a blog entry - to which I redirect you. Further analysis can be found on Ian Skerrett's blog - Ian is the Director of Marketing at the Eclipse Foundation.

Barely has my backside hit the office seat when I am off on a plane again, this time to the Eclipse Summit Europe.

Everytime I come to an Eclipse event I find out some new stuff. Here's one example: in STP, we've been doing some work on developer support for JAX-WS, code-first web service development. Here we've put together an annotations view, which allows the developer to edit the parameters of an annotation with support for validation of the annotation content, hints for enums, that type of thing. At the Summit, I attended a presentation by one of the guys from the Dali projectJPA uses Java5 annotations to implement its POJO persistence, so it makes sense that Dali have invested time in creating a Java annotation view, similar to what we've done in STP. The next job is to see how well the two approaches can be merged.

I was going to include the STP bugzilla link here, but bugs.eclipse.org appears to be suffering some database overload at the moment -- I'll update the posting later.

Here's a picture of an SCA composite, as found in the SCA Assembly specification.

What do you think? Pukka or pants? Personally, I think it's a bit inclined to the trousers side of the question. We all worked on the specification words, which were scrutinized most closely, but the diagrammatic representations didn't get much attention. Perhaps we are looking here at an interface designed by Engineers.

One of the things on the STP project plan is a graphical editor for constructing SCA composites from pre-existing service elements and allowing the compositor to wire up the various components and eventually package and deploy it to an SCA runtime. I'd like it to be a useful representation, however, and not something as clunky as what you see here. I know that many of you software developers are really frustrated designers at heart - what's your opinion?

I just got a comment on the blog recently updating me on an initiative which supports the build automation of Eclipse Plugins. Markus sent the link to www.pluginbuilder.org, where the eponymous software has just had a 0.2.0 release. Go try it out and see what you think.

Recently I've been having a most excellent time updating and building the SOA Tools project, constructing an update site and getting the infrastructure ready for the Europa (wiki link) release in the summer. It's all PDE, all of the time, and looking forward to a build matrix where we will have Eclipse 3.2.1 builds, 3.3 builds and a mix of J2SE 1.5 and J2SE 1.4 between the subprojects is interesting, to say the least.

However, things are hotting up in the Eclipse build world, and with projects like Kepler, Buckminster and ALF on the go, we are looking at a very interesting future.

Sunday is Day Zero of EclipseCon - traditionally a day for some introductory meetings and beers with people that you might not have seen, well, since the last Eclipse conference meeting.

Would you buy a Maven support license from this man? Phil Dodds, of Simula Labs and Kepler, in reflective form while waiting for the next mojito to arrive. I bet he's thinking about money.

EclipseCon is also a time to meet new people that you've only ever written emails to, or seen on dev lists and newsgroups.

Adrian Mos, from the ObjectWeb Team at INRIA, enjoying beer the quality of which cannot be easily obtained in Grenoble. Adrian is a JBI stalwart, and has been working with guys that created Cimero and ServiceMix to advance the state of the art in JBI tooling for Eclipse, and bring it to a home in the SOA Tools Project. This photo has been shamelessly plagiarized from Ed Merks' blog, so he gets a link. Thanks, Ed!

Next up is Day One - tutorials - and as usual there's great stuff on offer. STP's own Antoine Toulmé is doing a two-hour tutorial on our BPMN Modeler, which has attracted a lot of interest. I'm taking the opportunity to learn more about the Eclipse Debug Framework, and later on in the day, looking at how to extend the XML editors that are in WTP. At the end of the day, I'm closing up with some GMF domain-specific model stuff.

Carlos sums up the mood of the evening.

Last year I regretted not attending more of the tutorials, so this year I kept the schedule clear to let me attend as many as I could. Here's the experiences from the day.

A Tour of the Eclipse Debug Framework

This was a double-length (4hrs) tutorial that would take up the whole morning. My major motivation here was to get an idea of where I would start writing a BPEL remote debugger. I have some debugger coding experience: many moons ago I had spent a summer rummaging around in the belly of dbx , changing the remote debugging elements to allow it to debug bootstrap code on a uVax at the end of a serial line. Charged with this dim experience, plus a very long bittersweet affair with using debuggers to find bugs, I was really looking forward to this session, and I can say that I wasn't disappointed with the content and presentation. The link to the tutorial page above contains a link to a zip file with all the tutorial materials. Go and download it - if you use Eclipse for debugging your code, you should at least read it and see how the magic works.

After a break to miss lunch, I had two short tutorials lined up for the afternoon.

Extending the XML and source editors from the WTP Project

Part of the work SOA Tools needs to get sorted in the short term is an editing facility for SCA .scdl files. These files describe the structure of an assembly, and use an XML vocabulary. The current state of the art is a WTP XML editor, backed by a the SCA 0.95 schema and registered for .scdl resources. I'd like to be able to do better for SCA 1.0 when it is released, so I attended this session to gen up on the whole procedure.

The session itself was fine, the exercises were useful, but I got there a bit late after saying a few words at the membership meeting, plus I was missing something in my installation that cause things to go a bit tango uniform about three-quarters the way through. I adjourned for coffee and email at that point, but I certainly plan to revisit the tutorial materials that are posted at the link above.

Extending your DSM by leveraging the GMF Runtime

I work with some guys who do GMF programming and, frankly, I can't understand a single word they say at the standups. I attended this tutorial to try to remediate that situation, and to hopefully gain some kind of understanding on where to start on creating some domain-specific pictures for the SOA Tools Core Frameworks. One thing that was very useful was a run-down on what the GMF runtime provides - action bars, collapsible compartments, connection handles, geometric shapes, ruler and grid support, appearance properties and lots of other good stuff (especially: printing support!). The other thing was the discovery of inimitable GMF Dashboard:

They tutorial went on to show how to customize and extend your domain-specific model and to how to keep your crazy diagramming from eating EObjects. Unfortunately, I needed to peel off for a meeting before the tutorial had finished, but this is another one that I will be going through again offline.

These entries are being posted ex post facto to the conference - I just haven't yet got the hang of real-time blogging!

I managed to get one demo, one long talk and a panel in today. Lunch and part of the afternoon got subsumed by meetings and general corridor work. I was also developing some ideas to bring to the ServerSide Java Symposium in Barcelona in June. Here's the roundup:

Getting Hooked on Equinox

The presenters talked about and demonstrated two great applications of this technology. The first was the capability to load classes from a memory mapped archive or indeed shared memory, rather than from a JAR files. The second used AspectJ to weave incoming class files and instrument them for monitoring.

Extending WTP Using Project Facets

This long talk gave a full introduction to the facets facility in WTP. Facets can be associated with Eclipse projects, as metadata to describe capabilities, or requirements. For example, a project can be given the jst.web facet, to indicate that it is a web application. In this way, facets are similar to Eclipse natures, but the advantages that facets provide is that they are versioned and may have information about other facets that they require to function, and facets with which they conflict. All in all it's a cool approach and I certainly think we should consider using it in SOA Tools - we currently use natures to mark JAX-WS and SCA projects, but the versioning feature of facets would be very useful here as these approaches are standards and will move on over time.

Adopting WTP in Your Products

This session was a panel, hosted by Bill Roth of BEA. The panellists were asked a number of questions about how they have adopted WTP as part of their product suite. The most interesting thing I got from this session was an insight into SAP's open source strategy, which is more about take than give: the SAP representative on the panel showed some serious frustration at not being permitted by his employer to actually commit code back into the Eclipse commons. This cleared up something for me: I know that there are some guys in SAP Labs in Bulgaria (video link) working with SOA Tools, so on a recent IM session with an insider, I dropped some dark hints about contributions. The response was along the lines of "our Open Source strategy is difficult to explain". I guess that in the fullness of time, SAP will get its head straight on OSS and be more forthcoming. We live in hope.

Day 3, Wednesday, and at this stage in the conference I feel as if I have been dragged through a hedge. I'm not the only one, as lots of the people I've talked to have been here since Sunday and the adrenaline is starting to fade. This has nothing to do with a number of BoF sessions that provided free beer late into the night, nor has it to do with mojito-fuelled technical and project discussions. More on that in a later entry.

Today was the big day for the guys in the SOA Tools BPMN sub-project. I introduced their long talk From Modelling to Execution in the Enterprise - using BPMN and BPEL to a crowd of around 60 people, which was an excellent attendance. Antoine and Hugues did a a great job of bringing the audience through BPMN and how it can be mapped to and from BPEL.

I was due to do my talk on SOA Tools the next day, so an early night was in order. There was an IONA round-up at Pedro's and then it was back to base to sand down the corners of the presentation.

The last day of EclipseCon was SOA Tools talk day. I spent the early part of the day working on the presentaiton (which you can find if you follow the previous link). The talk itself went well - there was an audience of about 40 or so, and there wasn't much attrition towards the end. In the talk we covered some of the technology that had been put into the SOA Tools project, and gave an update of progress and a draft roadmap.

Recently in IONA, in an informal moment in the coffee area, a number of us sat down with sore heads and decided that we would all feel better if WSDL wasn't so hard to use. Not in those exact words, but I'm writing for a mixed audience here. In March, I was out at EclipseCon, and got to visit the Yahoo office (where old webservices comrades Mark Nottingham and Hugo Haas now toil). During lunch in the canteen, we talked about lots of things, but one of them was how we would all feel better if WSDL wasn't so hard to use.

There are of course lots of WSDL editors out there in the wide world. At Eclipse, there is the WTP graphical WSDL editor. Many products, such as XMLSpy and IONA's own Artix Designer incorporate ways to reduce the agony of dealing with WSDL.

For me though, none of editors I've tried have made the nut. As a developer I want a clean way to make WSDL that deals with all of the crud that needs to be there (like pointy-bracket syntax for example). What I don't want is a weird graphic metaphor with links and dragging and dropping, thanks. Just let me type it, like code, give me some syntax support and some useful conventions and then let some other agency worry about generating the XML vocabulary.

Here is the sort of thing that I would like to be able to type in and have it converted to WSDL for me, with some sensible defaults, etc:

We could also code in some conventions (like that version in the interface) to help people along, so for example:

would cause an error because someone has changed the method signature in a minor version upgrade. They should have used version 2.0 instead. There's little limit to the fun we could have with this :-)

By the way, the string type that you see there is, by convention, the XML Schema string type. Same goes for the float. You can use imported types just by using the prefix approach that XML already has - pfx:myType.

I haven't mentioned the bindings aspect of the WSDL specifically. To me, that part is a big target for an extensible set of wizards or tailored binding editors and not something that feels like it should be accessible to code-like definition.

It's getting near now - end of this week we are good to go for the Eclipse Europa release.

I'm looking forward to getting this out the door so that we can get back into a planning mode next week!

Well, it shipped nearly a couple of weeks now, and I've been taking a bit of breather and getting back in touch with some other things that get left by-the-by as we went through the release process. Bjorn and the legal team deserve great praise for their mammoth efforts in getting everything lined up for those of us who delivered projects.

From the perspective of SOA Tools, it's a time to gather our wits and make some plans, with the help of the community. I'm glad to say that over the last few months, there has been a considerable amount of interest in the project from a number of organizations that wish to contribute code and expertise. The PMC's challenge is how to make sure that all these prospective committers can work together in a way that is conducive to developing the best open source tools and frameworks.

Enter the Incubator. This is to be an STP sub-project (it's in pre-proposal phase right now), which I hope will address our challenge. It works like this -- a number of organizations decide they would like to contribute some code, but in each case, they have code that does the same or similar things. The best thing for the project is that the committers come together, bring their solutions to the table, re-architecting if necessary, and producing a joint vision for the merged code. The 'table' in that metaphor is the Incubator sub-project. Once the technical vision has been constructed and agreed upon, and a draft plan put in place, any work that has taken place in the Incubator is ready to 'graduate', that is, move to full STP sub-project status.

It's also time to let us know what you would like to see happening in the current areas of the project - let us know on the dev list or the newsgroup!

I'm waiting for my flight to Frankfurt to attend the Eclipse Summit Europe that is being held in sunny Ludwigsburg, in Germany. Due to a typical pebkac error, I'll be staying in 3 hotels over the 5 days that I will be there :)

The Euro Summit is an interesting conference - the content is usually good, the venues conducive to meeting people and of course the German beer is without peer. This adds up to a fun-filled few days. During the conference, Adrian from STP will be updating us on what's new and noteworthy on the project, and of course bringing us up to date on the old material too. One of the evenings will contain an STP BoF, although the date has to be confirmed.

I had the pleasure to share a drink and a chat last night with Ed Merks, the EMF Project lead. One of the interesting things that he brought up was his efforts to extend the EMF URIHandlers to be more REST-like. He mentions this in a blog entry - you will find the reference after the picture of the hibiscus. There are some more techcore details at the Bugzilla entry that hosts the patch.

This work is a big thing for EMF, in my opinion. Putting this together with a simple HttpService instance in an OSGi container can give you the basis for remotely manipulable models, with most of the work done by EMF itself. This opens up the field for Rich Internet Applications (blach - another buzzword) that can interact with hosted EMF models without having to depend on having an EMF library on the client side.

The Artix Repository product that IONA ships has done something very similar, but we have created the RESTful interactions outside of EMF. It's cool to see this kind of capability moving into the core.

Just got a link this morning to the C.R.A.P. metric and the crap4j Eclipse plugin. This humourously-named approach mixes up cyclomatic complexity and code coverage to give a number that is your code's CRAP index. Generally speaking, you can lower your CRAP index either by adding automated tests or by refactoring to reduce complexity, or both.

Apparently crap4j can also estimate your CRAP Load (we've beaten this one to death - ed.), in which it gives an indication of how many tests you will need to write to reduce the CRAP index to less than an arbitrary bar of 30.

Update: tried it out, and it seems interesting - I can understand the concepts immediately and it has an amusing toilet paper icon on the menu. Here's a screenshot of the CRAP Report that it produces.

In the case of this anonymous component, you can see that the crapometer weighs in at 14.91% - an artitrary figure that tells me that a little over one in seven of the methods in the component are, well, crappy.

The CRAP Load figure above hints that maybe about 14 tests would do the trick in reducing the CRAP figure of a complex method with 0% coverage.

Eclipse users and developers know that the Eclipse platform is a bit of beast - there is just so much in there that if you don't get the chance to poke your head out of your own personal Eclipse-interaction light cone, you can miss out on some cool stuff. And it turns out that the best way to do that is to come to these kind of conferences :) Here's some things I found out about yesterday.

Plugin Spy
Select something in the UI, hit Alt+Shift+F1, and you get a window containing an introspection of the current widget/part that you have selected. Check out the PDE Incubator page, and a blog entry from Chris. If you are using Eclipse 3.4M2 or later, you will find this feature already built-in.

Clean Ups
I use Checkstyle in most of my project work, and it and I have an uneasy relationship. The sort of one where the dishes get broken and people come around to bring the pets away. I have always whined that if Checkstyle is so smart, why doesn't it get rid of that trailing space it spotted for me and stop bothering me? Well, it can't do that, but Eclipse Clean Ups can. Woot!

A Clean Up is just a collection of refactorings that you use regularly on your code to keep it squeaky. You can run 'em manually, or have them run automatically when you save a Java file. Go to this developerworks article to find out more.

EclEmma
If you are familiar with the Emma Project then you will have probably guessed that this is a test coverage tool for Eclipse, based upon Emma. I've always found test coverage to be an invaluable tool for showing you where the great, gaping, black holes of non-deterministic behaviour reside in your code. There's a lot of tools that can do coverage, and there are Eclipse integrations at varying levels of quality. What I liked about EclEmma is that it is quick and straightforward to use on a single Eclipse project, and gives me the results fast. Although the results are not always welcome :)

Update: Jeff McAffer's Eclipse Update Talk [pdf link] has details of Plug-in Spy and Clean Ups.