Buddhika Laknath is hard at work on his XQuery plugin for eclipse. He had a big hurdle to over come, but with a few well hinted places for him to look at existing code, and few tips he's now making some good progress. Here's a screen shot:



After struggling to wrap his arms around the the SSE api and the XML editor code, he's now getting ready to tackle the fun stuff. SSE itself is not something that is easy to understand. Particularly how to get your own parsing implemented while leveraging existing functionality. In order to have mixed content you either have to write a new parser that understands both languages you want to mix, or you have to do some VooDoo magic underneath, by marking some partions, and then reparsing with your specific extension language parser. It's especially messy when you have to deal with several different Dialects: XML, XQuery, and XPath 2.0.

Hats off to Buddhika for plodding through, I think he can finally start seeing the light to some of the fun stuff.

Intalio provides a packaged version of the SOA Tools BPMN modeler.

Grab it here and start modeling in minutes.

Would you have any problems using it, please file a bug at the usual location or ask for help on the eclipse.stp newsgroup or by IRC: #eclipse-stp.

Cross-posting from the Intalio blog…

Thanks to Eclipse Ganymede Edition ... Browsing for IDs of Perspective, Views, ActionSets, Wizards etc was never this easy ... Earlier to Ganymede if i need to extend a Perspective .. i would use PerspectiveExtensions and then in the targetID would have to copy paste the ID of the perspective that i want to extend from somewhere ... Now it is just a click again .. You have a browse button just next to the targetID parameter wherein it lists all the perspectives installed in eclipse that you could extend ... The same applies for View, ViewShortCut, NewWizardShortCut, ActionSet etc ...

Hope you enjoi this feature of Ganymede ...

Eclipse plugins are written using Eclipse. The excellent Plugin Development Environment (PDE) is what you’ll need so if you’re on Fedora, try yum install eclipse-pde. If you want to hack on an existing plugin, check it out into Eclipse.

For example, say I wanted to hack on the specfile editor which is part of the Linux Distros project at eclipse.org. If it’s a good Eclipse project, it will provide a project set file that contains the CVS/SVN info for the various included/related projects. The specfile editor one is here. I download the file and then in Eclipse (assuming I have an SVN plugin installed, like eclipse-subclipse in Fedora) go: File->Import->Team->Team Project Set and enter the location of the saved .psf. If there isn’t a .psf file, you can always check the projects directly out of the version control system.

Once things have checked out, they’ll build and — assuming things aren’t broken in the revision you checked out — you can run it right away. You do this by launching a second Eclipse instance that uses a combination of the plugins running in your host Eclipse and the ones built in your workspace. Right-click on one of the plugin projects and select Run As->Eclipse Application.

Boo-ya! Any changes we’ve made in our workspace will be reflected in this running instance. In the future I’ll talk about debugging the plugin(s) you’re working on and how to create patches, etc.

There's an interesting article about use/abuse of email in the NY Times today:

I Freed Myself From E-Mail’s Grip

FWIW, I think ECF is doing it's part on this problem, by providing multiple ways for Eclipse users to easily, cheaply, and openly communicate and collaborate.

Also, for those interested, there is a longstanding proposal to add an XMPP server at Eclipse Foundation in order to help teams build and maintain community.

I am pleased to announce, that in cooperation with Poznan Univeristy of Technology, we are preparing next edition of Eclipse Summer School. We are going to teach students (and not only, companies are also welcomed) how to use Eclipse and how to create RCP applications.

The tutorial is 5 days long and we guarantee dinners, coffee, tea, sweets and a lot of fun!

You can find more details here: www.eclipsesummerschool.com. Unforunately the site has no English version, so please use google translate.

We are also looking for sponsors, so if you would like to look for new hires or to promote your company in academic environemnt, please let me know.

Regards,
Chris

PS. Last year 95% of particapants told us that they would recommend our training!

Ed Merk's latest blog posting about the marketing of various downloads, and the disappearance of the Eclipse Modeling Package to a sub link, corresponds in some ways to a post by Rick Jelliffe on Microsoft's participation in standards groups. How are the two related, by the following quote from Rick.

"One of the great disappointments of the open source movement has been the way that lazy users don’t feed changes and improvements back, but are passive recipients. And often we see open source programs reflecting the priorities of its sponsors not its users."

In some ways this is the same effect that is appearing on the popularity ranking of the Eclipse Download page, but it is a bigger issue than that. Like the adoption of Standards, it unfortunately isn't the users that are driving the changes of the standard, but the priorities of the sponsors. A balancing act needs to be made when doing either open source development and standards work. Which hat do you wear? Is it the community hat, or your employers/sponsors hat? Which one you wear affects everybody as a whole.

I'm a little disappointed now that Ganymede is finally out. Of course I'm generally in a funk whenever I actually reach whatever goal I've ever tried to achieve.


It helps to remind me that goals are nice for setting direction but are generally disappointing when you get there; it's best to enjoy the journey itself as much as possible because it lasts a lot longer than does the goal. But I digress, and so quickly too. Speaking of which, our neighbor had a very nice Canada Day party complete with spectacular fireworks.


Getting back to my disappointment, have a look at the Eclipse home page with its lovely moon shot that includes a "you can't miss it" link to the Ganymede downloads. It's just so clickable and soon you'll be at the Gaymede download page itself. But where the heck is the modeling package? And since I don't see it there, how do I find it? The navigation bar has a Download Packages link, but isn't that where I am already? As an exercise to the reader, see if you can figure out how to find it...


Well, if you hunt long enough, perhaps you'll find the "More Packages..." link in the far right hand column; it's not listed under the names of the other packages in the left column where you might find it more easily. This link takes you to the annex where the second class packages live; the ones not popular enough for the main download page with its precious real estate that's carefully tailored based on the "less is more" principle. You have no idea how much I dislike the "do more with less" principle; I'm sure many readers will understand exactly what I mean, but I digress yet again.


If we really wanted to do more with less on the main download page, isn't it a little odd that the page has a banner with a link that navigates back to the same page itself? Doing more with less seems to argue that a circular link along with a big banner are actually doing less with more.


Now have a close look at the 10 most popular projects on the right. Given EMF and MDT on the list, it's a little odd that the modeling package is so unpopular. And speaking of popularity, given that accurate download statistics can't be computed, 239389, what exactly does determine popularity? It seems to me that making something hard to find might well impact its popularity.


It's been argued that adding more packages would move the member distros farther down the page and make them less reachable. But if that's such a big concern, perhaps we should put the member distros at the top, and hey, we might even add a link for it in the navigation bar. After all, member revenue drives the foundation's budget and having your distro be prominently displayed helps derive value from Eclipse membership fees. Or perhaps the distros could be put side by side with the packages to make better use of the precious real estate. In any case, on a 1050 line monitor, the distros aren't visible anyway, so it seems like a weak argument at best.


Note that Borland, Itemis, and Obeo are strategic developers heavily invested in modeling so I expect some board discussions on this topic of membership value on the main download page. I think the random appearance of distros along with their own separate overflow page is also kind of bogus.


It all makes me wonder if it wouldn't be better to have an expansion swizzle that lists additional packages/distros on the same page rather than having to navigate to a different page? Or even just to make the overflow link be more noticeable? Of course I'm far from being an expert on marketing or proper web page design, but I'm disappointed that the main download page is picking favorites. No matter how you look at it, it's certainly clear that the current approach doesn't market Modeling well at all, and that fundamentally disappoints me.

This morning I gave a presentation at the Java-Forum-Stuttgart conference on Aspect Weaving for OSGi. The slides of this talk are now available for download:

• Aspect Weaving for OSGi (pdf)

The code for all live demos from the presentation will follow shortly.

The Code Generation 2008 in Cambridge (UK) has been real fun. Karsten, Sven, Peter and me, we have met a lot of interesting people from the model-driven / DSL world, and have heard lots of interesting views and news on code generation.

The best thing in a conference on code generation is that the participants are already convinced of the benefits of modeling, so you don't have to explain every time from the very beginning why you think modeling is a good thing.

Last but not least, our workshop on openArchitectureWare was very successful and we has been rated top by the participants. It feels good to be assured that we are working on the right things.

Text editor is a UI component that can display any file content inside eclipse in a textual format. In reality every text editor has a textViewer or a special kind of textViewer called as sourceViewer which basically displays the file that is open. Every Viewer requires a model as input to display some content on the view. Therefore the input for textViewer is an object of type IDocument.

If you have a question about some Eclipse project, the newsgroups are your best bet.

If you’re not sure what group is appropriate for your question, post it on newcomer. Posters to newcomer are often redirected to other newsgroups, but newcomer is a good starting point since a lot of very knowledgeable people watch the group pretty carefully.

The newcomer group may be misnamed. While it is indeed for newcomers, it’s not exclusively for them. Lots of folks who have years of experience with Eclipse post their questions there.

The newcomer newsgroup isn’t just for newbies. Can you think of a better name?

Massively parallel computing is something I've been interested in for a while and have blogged about a few times in the past. This blog entry by an Intel Researcher made me think about it again. He continues to proclaim that the future isn't that far away and we had better start designing our software so that it can run on machines with thousands of cores. He worries that we're aren't ready yet and we need to start getting ready. And he's right.

Being a tools guy, I think this is the next big paradigm that the tooling industry needs to address. Object-oriented programming and design was a godsend when machines started scaling up in the size of memory and storage and our programs began filling that with data. We built a lot of tools to help with that. Programming languages and compilers are obvious examples. But so is the JDT and CDT, with their code analysis to show type hierarchies and help you easily find classes. Not to mention all the object modeling tools for drawing pictures of your classes.

Coming up with the languages and compilers and other tools necessary to deal with thousands of concurrently running threads is our next great challenge. This is why I keep one eye on the Parallel Tools Project at Eclipse. They're already in this world dealing with the thousands of processors that run the super computers they work with. This effort is a research project in itself (quite literally if you notice who participates in this project :).

But as the Intel researcher warns, this stuff is going to hit the mainstream soon. We're starting to see that with OpenMP parallel language extensions supported in almost all recent compiler releases, including gcc. And I'm convinced it's an area where modeling can help since you really need to think of your program in multiple dimensions, which is something modeling is good at.

I think it's a matter of time before we're at the head of a new paradigm. I remember the fun we had when object-oriented programming hit the mainstream. I think this one will be just as fun.

Like Evil Dead 2, this “remake” of 2006’s Build Workshop was far more groovy than the first, in terms of special effects producing concrete results. I look forward to the next one… perhaps in the fall, when the leaves are turning and I need to get out of Toronto again? I could see these workshops becoming a quarterly event, if nothing else to keep people talking about and actively working on this issue. Facetime is important, especially when we’re all otherwise swamped with Real Work ^tm.

While the last one produced ideas, plans, and documentation about best practices, it failed to materialize its one big requirement, which was a commmon build infrastructure, hosted at Eclipse. I’ve since created documentation ([1], [2]) for doing a DIY build server, which has been successfully implemented by at least two projects. But it’s still fairly labour intensive, and it’s tough to share.

This time around, we focused on something that’s been on my TODO list for about a year: running my build system on build.eclipse.org. We’d originally planned to produce a vserver image or vserver config script, but since there’s still ample work to be done to genericize my existing image to work outside Modeling, this seemed a shorter initial path to prototype. And the fact that we can’t distribute such an image (because of all the GPL code in a Linux distro) was also a bit of a blow to the idea.

Bjorn and Denis, in trying to understand a little of the madness that is my system, have made me revisit all my original assumptions and requirements, to ensure they’re still valid, and that there’s not a better approach. I love having my assumptions challenged — it’s the only way to prove a system matches its demand, and that I’m not simply stagnating under a mantra of ‘because that’s how we’ve always done it’. (It’s sort of like my attempt to challenge the assumption that next year’s coordinated release should be called “Io”… but I digress.)

One thing we are still clinging to, for this first iteration at least, is that we’ll be building all-java, single-platform builds, for small projects & components who want a website with downloads, an update site, p2 metadata, jar signing, pack200 optimization… and little or no overhead in terms of infra setup. So, this solution will NOT address complex builds like the Platform, WTP, TPTP, or product builds. This is strictly (for now, anyway) designed to ease the burden on developers who don’t want to have to care about web/build infra. Of course none of this addresses the releng code that defines WHAT and HOW to build — it only enables a faster route to market for running and publishing builds. If you’re a project of the size of VE, PDT, or STP — or something smaller — this system’s for you.

Building anything more complex remains out of scope for now, and I admit freely that some of the reason for that is that Denis doesn’t do builds, Bjorn does small Technology Project builds, and I do Modeling builds — none of which motivates us to spend effort solving problems we don’t (yet) have. For 2 years my system didn’t do UI testing, because until UML2 Tools & GEF joined the party, there was no need. Now there are several projects w/ UI testing, so the system allows for that.

What is in scope is to explore the use of the Cruise Control interface to improve build scheduling and queuing, so that we can better manage disc and cpu usage. In time, the hope is that if a build queue gets too long, we’ll have statistics to back up the claim that we need more memory, cpu, or disc space, in order to better meet demand.

Clearly, I have a lot of work ahead of me, but today showed that both Bjorn and Denis are willing help out here. (That’s not meant perjoratively — only that we all have other time constraints pressing on us, but that we’ve collectively agreed to set aside cycles to focus on this.)

Here are the five pieces that must come together to make a build system work:

1. properly defined features and plugins — the responsibility of the component lead
2. a .releng project (or perhaps a Buckminster project?) to define what to build, what order to build, when to test, and HOW to package — shared responsibility between component lead and the release engineer, if your project is large enough to have one. Note that for these first two, my Summer of Code student is exploring the use of JET to produce wizards to guide this process and make it a little more friendly and less RTFM’ish.
3. UI to run builds on demand
4. UI to validate builds (JUnit results summary, links to build metadata like logs and config files). This could be views in Eclipse, but because publication involves putting bits on a website, it’s currently handled predominantly as PHP (with some Ant and bash scripts)
5. UI to publish acceptable builds to Eclipse.org & generate other build output (eg., an update site, Ganymede site contribution file, etc.); this could be merged into the build itself, but I split it because IMHO not all builds need to be published, and generating all the extra meta isn’t required when all you want to do is test the user’s install experience with your project. But of course this assumption can be challenged…

Then, in terms of automation (and places we can improve), there’s:

1. feeding the latest dependencies to the system so that when a new Platform (or EMF, or GEF, etc.) is available, the ad hoc and automated builds can simply use that new dependency. RSS feeds of course come to mind here, which though I was a big proponent of, haven’t really done much with (insert age-old “time constraints” excuse here)
2. scheduled builds are great, and can be set to run only if CVS has changed, but continuous building might be handy too. However, it’s important to consider how often to check CVS for changes [frequency], what’s considered a complete change (vs. part of a series of commits) [threshhold], and where to check [all the sources? or just the mapfiles]. Build too often & you’re wasting others’ cpu time. Not a big deal when there’s only 3 builds on build.eclipse.org, but if all 20+ Modeling builds move there… sharing and coordination suddenly becomes very important. And if your project consists of less than, say, 5 committers… do you really need continuous builds?
3. automated cleanup of old dependencies so the UI stays clean and disc usage is kept reasonable

And then, of course, there’s room to improve integration.

1. supporting Subversion sources
2. supporting Maven-based dependencies
3. converting bash scripts that “do work” to Ant scripts w/ custom tasks; submitting these back to PDE build or releng.basebuilder for reuse
4. converting bash scripts that “do calculations” to PHP-based web apis, so they can be called by web, shell, ant, or java
5. porting configuration parameters to the Portal

At the end of the day, we had:

1. evaluated Maven, Buckminster, PDE Build, basebuilder.releng, and the stuff I’ve done to simplify the PDE/basebuilder experience
2. successfully run the GEF build on build.eclipse.org (with some UI problems to be fixed, and at least one failing JUnit test)
3. implemented code to extract build parameters from the Portal instead of from static php config files; testing and iteration TBD (probably more things to add/remove/simplify)
4. created a way for the genie daemon to run builds launched from the web or crontab (but jar signing fails as we longer need to push bits to build.eclipse.org)
5. dumped a lot of the “common modeling build” code into a new Dash project, org.eclipse.dash.commonbuilder, which will house common web UI, server config scripts/properties (eg., paths for JDKs & build folders), and build/promote scripts
6. begun scripting the process of bootstrapping (or updating from CVS) this common builder, so it’s reproducable and hands-off; verification TBD

If that doesn’t sound like an exhausting enough day, have a look at this.

---

Note that this is not a project plan, and until one is drafted, nothing is set in stone. More people willing to help will of course allow more things to get implemented. So, does this project interest you? Are you willing to contribute time and effort kicking its tires by porting your build to this system, in order to make it better for all?

Eclipse Ganymede and P2 will change your update workflows from ground up. There are some Cons (I'm missing the external locations from Software Update), but many Pros so for me its time to change. If you don't want you can still use the old Update Manager. (Preferences - General - Capabilities) There are many new things in P2 - today I'll concentrate on: Dropins - a folder where you can

Today I tried again my workflow to install some shared installations and prepare a new blog about it. Suddenly P2 Installer doesn't run any more. (you should read my blog Eclipse Ganymede - P2 Shared Installations (Bundle Pool) to understand the whole story ;-) I deleted /configurations/.settings and /p2 from P2 Installer directory and started P2 Installer again. This time I got a message and

The JAOO folks have kindly recorded my 2007 presentation on managing variability in product lines (slides). Among other things, it showcases some of the PLE features available in openArchitectureWare.

Ubuntu includes Compiz which provides fancy desktop effects. Unfortunately it does not play very well with Java. After enabling Compiz, I have seen seen numerous empty Swing dialogs in soapUI . This is a known problem in Java. The bug report claims it is fixed in 1.6.0_10 but the Ubunu repositories still have Java 1.6.0_06.

There is a workaround to prevent the empty dialogs. Add the following line to your .profile file:

export AWT_TOOLKIT="MToolkit"

Today I tried to install the Eclipse plug-in of soapUI and I discovered that the workaround breaks the SWT_AWT bridge in Eclipse. Bug 208968 mentions a workaround but it requires a code change so I'm stuck.

I guess I'll open a soapUI bug and continue to use the Swing version instead of the Eclipse plug-in (which is a repackaged Swing version anyway). If you were able to get the Eclipse plug-in of soapUI working in Ubuntu with desktop effects, let me know.

We are seeing more and more outlines appearing for the next OSGi release. One of the major issues is legacy code. Not only inside the OSGi, but if you go to the web you see a lot of people struggling to get old code to work inside OSGi frameworks. Obviously, we want to mitigate the issues around legacy code as much as possible, the more people that use OSGi the better. However, lately I have some (personal, this absolutely is not an OSGi standpoint!) musings about how to attack the issue of legacy code.

A short story to illustrate my musings. In the eighties, I worked on a page-makeup terminal for the newspaper industry. Petr van Blokland, a graphic designer turned computer specialist, introduced me to the layout grid. This grid had columns and between the columns there was a small gutter. Text and pictures were placed on this grid, usually encompassing multiple columns and gutters. Like:

The OSGi always reminds me of this grid. Why? Because they both restrict you severely but in return they provide simplicity. Instead of having infinite freedom to do whatever you feel like, you must obey some pretty basic rules, which some people find upsetting. But what you get back is that the elements work together as a whole, instead of fighting with each other.

Layouts done with this grid almost invariably look good with no effort (try working with the average layout manager in Swing or SWT!). The advantage is that elements always line up and there is always the same space between elements. Without a grid, it is very hard to avoid unwanted visual effects.

Genuine OSGi bundles almost invariably collaborate with each other without much effort (anybody saw the combination Eclipse and Spring coming?) because modules are self-contained and can only export packages and communicate via services instead of the myriad of ways people have devised in Java.

Interestingly, both are achieved by restricting ones freedom, the opposite of providing more features. But neither OSGi nor this grid is simplistic. A simplistic grid would be a square 8x8 grid, and they just do not work. A simplistic OSGi would be some Class.forName based system without handling versions and dependencies. Both OSGi and the grid seem to be in a sweet spot: simple but not simplistic, providing maximum bang for the buck.

However, legacy code seems to be forcing us to add more and more mechanisms to the OSGi specification. Unfortunately, these mechanisms are often also then used for new OSGi applications because the legacy concepts they represent feel familiar to people. See how many people use Require-Bundle and fragments.

If we add all these freedoms to the next generation, will we not pollute the original model and become in the end much less attractive? Or, if we do not make it easier to use legacy code, will people turn away because they feel affronted that their direct needs are not addressed? Should we leave these issues to framework implementations making legacy code not really portable?

The current popularity of OSGi seems to allow the OSGi to make a stand. What do you think?

Peter Kriens