This just in, Aaron LaFramboise has just released an alpha version of gcc 4.3 for MinGW. And, of course, they are looking for testers. I know I will be. You can give it a try to by downloading it off of mingw.org. I've been following the mingw-users mailing list and it's been a great place to discuss issues. It's not too busy but it's been busy enough to be useful.

gcc 4.3 in combination with the new gdb 6.8 really brings the MinGW port for native Windows up to snuff with the gnu toolchain enjoyed by Linux developers. And I think it has a chance to give Visual C++ a run for it's money. Time will tell of course, and I am wearing my open source colored glasses. But as with the CDT for Windows development, all we're trying to be is a respected alternative and a valid path for multi-platform development.

Speaking of which, it's getting time to start working on Wascana 1.0. It'll be based on the Eclipse Ganymede with the latest tools from MinGW as well as a handful of libraries to help build platform independent apps. And it will use the Eclipse p2 provisioning framework so you can install and update the tools and libraries using the same UI you use for plug-ins. And with 7000 downloads of the last Wascana prerelease, it's worth the extra time I have to put in to make it happen.

If you're a UI developer in Eclipse, you probably come across one of these issues:

• fighting layouts
• fidgeting with margins
• pushing pixels
• etc...

You probably also came up with some hack to add borders to composites to help with these issues. Well, at least I did.

Why am I bringing this up? Well a few days ago, Simon Archer and I were discussing how new GridLayout() can be bad since it sets default margins and how it can be difficult for people to realize this amongst other layout issues. To ease some of these issues and stop the madness of duplicating debugging utilities, Simon and I decided to start a new work area in PDE called Picasso. The purpose of the Picasso work area is to provide a utility to help UI debugging. Picasso does this by painting the workbench in funny ways to aid debugging :)



The screenshot above shows Picasso painting the preferences page's composites. Picasso also allows you to hover over widgets and provide some raw debug information.

How do I use Picasso? Simply grab the code from the PDE Incubator and launch some runtime workbenches. Or you can build yourself a version of the Picasso plug-in and drop it in your application to see what's going on.

Note, Simon and I are just providing Picasso as a utility for people to use, we don't have crazy plans on maintaining it unless the community steps forward with patches and ideas. It's just a work area that maybe useful to some.

Enjoy.

Just a reminder: the Eclipse Stammtisch in Hamburg will be this Monday (May 5th) in the Bolero Bar in Hamburg Ottensen. Google Maps: click here (opens in separate window).

If you haven’t done so, please RSVP using our Doodle poll: http://www.doodle.de/ics.html?pollId=gbzrpc86xkyhbv5k .From what I can see, we’ll be at least 20 people and there will be some well-known faces.

Hope to see you there!

Since not really visiting EclipseZone and javaLobby past its new incarnations you may be wondering where those communities moved to. I have found that you can find the members for those communities on FriendFeed and Twitter. I was surprised by the number of folks that I have conversed with over the years as a JavaLobby and EclipseZone member that are on both services.

The next chapter of “OSGi in Practice” is available for download from the index page. This one is an Introduction to OSGi Services.

I have also made some updates to the last two chapters, so if you previously downloaded them then you might want to get the new versions.

Please keep the feedback coming! Thanks again for all the feedback so far, it’s been extremely useful.

Eclipse 3.4M7 is out the door making 3.4 pretty much feature complete!

Check out the new and noteworthy.

A lot of thanks is owed to the work done by the Platform Releng team to make this happen. I hear they like chocolate :)

A special thank you should also be sent to the Equinox p2 team who spent countless hours above their normal work hours to make sure we have a new update story for 3.4!

Thanks to everyone!

The Visual Editor is moving to new software on a new server. I will leave this server up for a few weeks. Unfortunately, permalinks will break, but all the interesting old content has been migrated to the new server.

Why? Because I want a better platform than just a blog to talk about [...]

On a lighter note, an Europa StartUp screen:

On April 27, PlanetEclipse.org turned three! The site went through dirty diapers, teething, terrible twos and has now all grown up into a toddler of a site (can you tell I have a toddler at home??).

The original suggestion came from Ed Burnette (see above link). Gunnar went ahead and set up the first Planet on his own servers and eventually transferred everything over to eclipse.org.

Happy (belated) birthday, PlanetEclipse!

Dave has blogged a couple of times recently about his thoughts on standards development. As someone who is actively participating in the submission and revision of several specifications (some of which are standards) at the OMG, these comments certainly hit home. I agree that it’s typically 10% of the contributors that tend to do 90% of the work, and too often it seems that I’m among the “lucky” few...

One of the challenges of developing an OMG specification is the lack of tooling support for CMOF (Complete Meta Object Facility) models. This was one of the many topics that were discussed during the “Mega Modeling Mania” BoF (and again during the Eclipse/OMG Symposium) at EclipseCon in March. Based on those discussions, there does appear to be some demand for tooling that will make it easy to create, serialize (in CMOF-compliant XMI), and document metamodels that form the basis for open specifications. In response, I agreed to coordinate a proposal for a new component in the MDT project (tentatively dubbed “Metamodel Specification Tools”, or MST) to provide this kind of tooling at Eclipse.

The idea would be for the MST component to customize and/or extend the existing (or forthcoming) UML editors (primarily for class and package/profile diagrams) to expose CMOF concepts which are missing in UML (like identifiers, namespace URIs, and XMI tags), leverage the CMOF (de)serialization support that was introduced in the UML2 component as part of the Ganymede release, and provide a mechanism for generating a specification (or at least a decent boiler plate for one) directly from the metamodel using BIRT. Of course, it might also be desirable for the component to automate the mapping between a metamodel and its profile representation (if there is one) and possibly to make use of the Eclipse Process Framework (EPF) to document and coordinate the specification development process. If you’d be interested in contributing to such a component, I’d like to hear from you!

BIRT supports drilling down from a master report to a detail report. To facilitate this feature, BIRT provides a Hyperlink Options builder.



To drill from a table data element, the developer can select the data element, choose the hyperlink property and click on the ellipsis. This will launch the Hyperlink builder. Once the builder is launched, select the Drill-through radial, select either a report design or report document to drill to and supply any needed parameters. Parameters are often based on the current row value of the master table. That is all that is needed to create a master detail report, but suppose you want the detail report to be based on report parameter or some other variable. One way of accomplishing this task is to call the Design Engine API from script and modify the design at runtime.

For example suppose you have a master report and you want the detail report to be based on report parameter. You could define a report parameter for the master report that contains the name of different report designs to be used as a detail. The follow report parameter illustrates doing this with a static list box parameter. Its values are DetailOne and DetailTwo.



Next select the data element that you want to link, select general properties and name the element. In this example it is named mydataelement.




Finally enter script similar to the following in the beforeFactory script event.
importPackage(Packages.org.eclipse.birt.report.model.api);
importPackage(Packages.org.eclipse.birt.report.model.api.elements);



dataHandle = reportContext.getReportRunnable().designHandle.getDesignHandle().findElement("mydataelement");

ac = StructureFactory.createAction();
ah = dataHandle.setAction( ac );
ah.setLinkType("drill-through");
ah.setReportName( params["detailrpt"].value +".rptdesign");
ah.setTargetFileType("report-design");
ah.setTargetWindow("_blank");
pb = StructureFactory.createParamBinding();
pb.setParamName("order");
pb.setExpression("row[\"ORDERNUMBER\"]");
ah.addParamBinding(pb);





This code creates a drill-through hyperlink on the fly and sets the detail report based on the report parameter with this line of code:

ah.setReportName( params["detailrpt"].value +".rptdesign");

This example is available at
BIRT Exchange.

Digging through my email backlog, I found this post on the google-summer-of-code-announce list, which reminds us that it's time for the Google-O'Reilly Open Source Awards for 2008 (nominations due by May 15).

Then I saw this... ;)

Ubuntu has done more to promote a desktop Linux than any other distro before.

---

And yet as a company contributes so little development resources.

---

You clearly do not understand open source. Like someone said the other day, all companies work together in the Linux desktop: Red Hat fixes the kernel, Novell fixes the applications, and Canonical takes the credit.

It's all a team effort.

Anyway, while successes at Eclipse are *also* the result of team effort, these awards are for individuals (the good kind, not the Teflon kind), and you can invent your own award titles. Enjoy!

I just went through some blogs and the Adobe Open Screen web site to try and understand what's going on. If you haven't heard, Adobe is removing licensing restrictions on it's SWF and FLV/F4V file formats that serve us Flash content and all those crazy videos on YouTube and such. In the past, the license on the specs restricted the reader from creating competing players, which has resulted in some pretty weak open source players that relied on the developers reverse engineering and guessing at what the spec is.

Opening the specs makes that no longer an issue. But the other announcement, that Adobe is going to make its player free for embedded devices as it does with desktops should really remove the need to have other players (which appears to be the true objective of this project), except for the open source bigots who must have their apps served open sauce, I guess. Bringing a free Flash player to devices is huge in my books and with their porting layer APIs made public, that should make it really easy for device developers to port the player to their devices. I think that's pretty game changing and you'll start seeing more Flash-based user interfaces on devices over time.

So it seems like pretty exciting news and it'll be interesting to see where it goes. But, I do hate the fact they're using the term "Open". This is one of my dogmas as colleagues that I've worked with in the past are painfully aware ;). "Open" is too tied to the word "source". And especially when the project is called "Open Screen" it's to easy to jump to the conclusion that they are actually open sourcing their player technology. But from what I can understand from the brief FAQ's they have on their site, I don't think they are. Which then begs the question how do you get their player running on your device. Do they have pre-compiled binaries? Which libc? Which OSes? Which compiler? At any rate it has left me confused and I'm sure others are. I wish people wouldn't use the word "Open" unless they really mean Open Source.

You may already know about Eclipse IRC channels on irc.freenode.net, such as #eclipse, #eclipse-modeling and #eclipse-soc.

However if you need some help with Maven and Eclipse, you may also consider #m2eclipse and #maven channels on irc.codehaus.org.

See Eclipse IRC FAQ for more IRC channels related to Eclipse and for setting up an IRC client.

It is a fact, web applications become asynchronous. AJAX maked end of long response time due to the old practice of response-loop request to load a whole page. Before AJAX this technique was already used with a hidden Applet which accessed to a MOM (Message Oriented Middleware). Do the MOM become itself as the exchange architecture the most appropriated for web applications ?
(more…)

Event Date: August 6, 2008 4:00 pm GMT-8

Register Now

Event Date: July 15, 2008 4:00 pm GMT-8

Register Now

I know, I know…shame on me for taking so long to become a Friend of Eclipse or FOE. I've paid my dues to Eclipse in a lot of ways, and now I can add Pay Pal to that list.

What prompted me to do it? Altruism, love, sense of obligation or duty? Nope…bandwidth. I'm working from home today, where I have a very fast Internet connection (unlike work). But the download from eclipse was really dragging. So I became a FOE, used the FOE mirror, and got some very nice download speeds. Totally worth the money. Hey…at least I'm honest.

You know what they say: "Keep your friends close and your FOE's even closer."

Life is about to start getting a lot easier for enterprise application developers. Last October, my JDJ article concluded with the following statement:

Eclipse plug-in developers are already spoiled with a dramatically easier way of building applications and are incapable of going back to a day in which the IDE support did not provide them with this high level of automation at both the language and component level. While the much more heterogeneous nature of JEE applications makes this kind of automation more challenging, the latest developments in the Eclipse WTP and Mylyn frameworks provide key enablers. It is high time that Java EE developers start feeling spoiled by their tool support as well.

Today’s announcement of the OSGi-based SpringSource Application Platform seals the deal. Consider the facts that Java is a great OO language, that OSGi is arguably the best component model to date and meshes perfectly with Java, and that Spring is the de facto programming model for reducing the complexity of enterprise applications. What’s clear from the announcement is that these three modularity technologies will work together seamlessly on the server side.

The final thought to keep in mind is just how far this combination of Spring, Eclipse and Mylyn can go. The static nature of Java and the quality of the OSGi component model have made it possible for Eclipse to provide a remarkable set of productivity features such as consistent refactoring across Java and plug-in resources and easy launching and debugging of plug-in based desktop applications. The Spring Framework is building on the very same Java and OSGi technologies…

The neat thing about good modularity is that it makes a tool builder’s life dramatically easier. Consider how Java’s type system enabled content assist and the browsing of type hierarchies. Or how the use of OSGi by Eclipse’s plug-ins allows you to stay sane while dealing with hundreds of plug-in versions and dependencies. Modularity technologies make it easy to navigate and browse the entire structure of the system, enabling Mylyn’s Task-Focused Interface to ensure that you only see the parts relevant to the task-at-hand, no matter how large that system is.

To date Eclipse developers have been spoiled by the PDE’s plug-in and feature editors, which make it easy to evolve large Eclipse-based applications. Today’s announcement means that the same component model will now be working on the server side. The IDE support is evolving alongside the Application Platform, and leverages WTP, Spring IDE and Mylyn. Here is a teaser of the Eclipse-based tools:

Tasktop Technologies has been having a great time working on these tools with SpringSource, and you can expect a lot more Eclipse-based innovation coming from both the commercial SpringSource Tool Suite and the open source SpringSource Application Platform Tools.

The Dash Project's commits explorer has been a popular site since Bjorn and Ward first brought it out. Nick Boldt contributed a bunch of additional scripts and gave it a face lift and I added SVN integration. There is a lot of interesting data, but you always had to really want it. Dash was always that old motor home lumbering in the slow lane. Useful, and full of great stuff, but slow. We've had a lot of commits in the whole history of Eclipse and that leads to lots of data, which leads to slow queries.

AMD to the rescue! We migrated the Dash back-end database to one of our spanking new AMD servers (pebbles) while leaving the front end on the same vserver that has hosted it for the last 9 months or so. Here are some numbers Denis (who did most of the leg work) ran for comparison:

SELECT YEAR AS X, COMPANY AS Y, COUNT(*) AS COUNT FROM commits WHERE TOPPROJECT LIKE 'eclipse' AND PROJECT LIKE 'eclipse.platform' GROUP BY YEAR, COMPANY;

dash: 17.83s
pebbles: 2.66s

That's huge...

SELECT YEAR AS X, PROJECT AS Y, COUNT(*) AS COUNT FROM commits WHERE TOPPROJECT LIKE 'technology' GROUP BY YEAR, PROJECT

dash: 1m7.64s
pebbles: 6.47s

HOLY SMOKES. That's a bit different.

SELECT YEAR AS X, PROJECT AS Y, COUNT(*) AS COUNT FROM commits WHERE TOPPROJECT LIKE 'tools' GROUP BY YEAR, PROJECT

dash: 8.56s
pebbles: 1.74s

Try it out... if you remember that old lumbering motor home, you'll like the new big block transplant and aerodynamic treatment.

SpringSource’s announcement yesterday was not a big surprise — especially after they hired Glyn Normington, an OSGi heavy-hitter who previously worked on turning IBM WebSphere Application Server 6.1 (WAS) into an OSGi-based platform.

Like the famous Curate’s Egg, the SpringSource Application Platform(S2AP) is excellent in parts, and I definitely recommend sampling the good bits. However, eating the whole thing might leave you feeling a little queasy.

Here are the parts that I really like:

1. SpringSource has made a strong statement in support of OSGi, not just as an internal implementation detail for a server platform, but as something that should be available to all developers. Most JEE application servers are moving to OSGi or have already done so, but at present they use it only for their internal implementation, i.e. I can’t deploy a bundle to WAS and start consuming services published by the platform. In S2AP I will be able to do that. This is a huge advance because it opens up the benefits of modularity and dynamic deployment to “ordinary” developers. Rod explains these benefits in an interview with Geertjan Wielenga on JavaLobby.

2. As part of the platform, they are providing a repository of common open source libraries with accurate OSGi metadata. One of the biggest hurdles to getting started in OSGi is in finding or creating “bundleized” versions of the libraries one needs to use. More and more open source projects supply OSGi metadata out of the box, but there are still many that don’t. While there are existing repositories like this, SpringSource’s appears to be one of the most comprehensive and high quality. Incidentally SpringSource were recently criticized for not “eating their own dogfood”, i.e. for running the main Spring website on a PHP-based publishing platform. But this repository appears to be running on S2AP; take a look at the 404 page. In fact, might this be the first example of a production S2AP application?

3. Spring Dynamic Modules (Spring-DM, formerly known as Spring-OSGi) is a great way to marry the traditional Spring Framework with OSGi services, substantially simplifying the programming model for services… although it’s not the only programming model in town for OSGi developers. For anybody already using Spring but not yet OSGi, Spring-DM offers modularity at the application context level with on-the-fly updates to beans. Spring-DM has been available for a little while now but is obviously an integral part of S2AP.

4. Assembling all the bundles necessary to build an enterprise application in OSGi has previously been something of a chore. S2AP will contain all the commonly needed parts in a single download, along with (presumably) some management tools, installation process etc. This is great for getting over the initial “Where do I start?” problem.

Now, here are the things I’m less than thrilled about:

1. There are two new bundle headers, Import-Bundle and Import-Library. As far as I can see, Import-Bundle has exactly the same problems as Require-Bundle. The new header simply provides indirection, i.e. you supply a logical bundle name rather than the actual Bundle-SymbolicName. This doesn’t fix the issues with binding to the wrapper around a set of packages rather than the packages themselves. Import-Library appears to be even worse, as it performs an Import-Bundle over a whole set of bundles at once!

   The documentation even admits that, using this approach, you will end up dragging in far more imports than you actually need. But it adopts the attitute that convenience is more important than correctly expressing the dependencies of your bundles. Needless to say, I disagree.

   Now, I admit that Import-Packages can be burdensome, but to solve this I think we just need better tools. I think Eclipse PDE could offer more help, for example, and it has been gradually improving in this area. Peter Kriens’ “bnd” tool is an excellent alternative: it uses bytecode analysis to include all the dependencies, and ONLY those dependencies, that you actually use.

   Luckily, Import-Package is still available in S2AP if you wish to use it. I strongly recommend avoiding both Import-Bundle and Import-Library and sticking with the standard Import-Package header.

   One question regarding these new headers is how they are supported by the tooling. I assume that SpringSource are leveraging Eclipse PDE for their development tools, in which case it seems they must have extended PDE. In fact tooling in general was not mentioned at all in the S2AP announcement. I wonder if there will be any support for non-Eclipse users?

2. The announcement makes it clear that a substantial amount of effort has been put into proprietary extensions to OSGi, in order to support some existing libraries, particularly ones that have issues running on vanilla OSGi (e.g. Hibernate), and provide “Load Time Weaving”. It’s not clear what those extensions are or how they work, but it is clear that they only work on one OSGi implementation: Equinox. I have blogged previously about the risks involved in supporting only a single implementation of OSGi. Also, I feel that they may simply not be necessary for many users of OSGi: not everybody needs Hibernate, even in the Enterprise space. Also other people have clearly been able to use Hibernate in an OSGi context without SpringSource’s help. So it remains to be seen how valuable these extensions are.

   The best I can hope is that if these extensions really are necessary, then SpringSource’s work will be fed back into the OSGi standards process and appear in a future release of the specification, so that other frameworks can implement them too. In the meantime it feels risky to rely on them, in the same way as relying on Equinox’s extensions makes me uncomfortable.

Anyway to summarize, I still think that yesterday was a great day for OSGi, and for SpringSource, and of course for enterprise developers. S2AP is not perfect, but I still hope it gains widespread use. Just stick to the OSGi specification and you won’t get hurt!

Over the last couple of weeks, I’ve been rebuilding the way the Modeling Project’s update sites work. There are a number of reasons for this:

1. To provide a Milestone (S) update site, separate from Interim builds (I & M), in accordance with what GMF & GEF used to provide before they adopted my build system.
2. To reduce the disk footprint that has over the years gone from reasonable to insane, and make it self-cleaning.
3. To provide site digests for improved performance.

The upshot is that I now have a system that incrementally adds new builds’ jars to the site, cleans out any obsolete jars (ie., if replaced by newer version) and regenerates both the site.xml and digest.zip for the site. Instead of 7.9G, the 7×3 sites (EMF, EMFT, MDT, M2T, M2M, GEF, GMF) now occupy 1.3G.

How does it work? Read on. Don’t care? Skip here.

It all starts with either:

• an SDK zip (or a few zips, if you produce more than one like GMF),
• a “Master” zip (the result of collecting all your build’s features and plugins into a single zip, then sending it to build.eclipse.org for signing), or
• an Update zip (much like the SDK, but including a site.xml file and with the jars in plugins/ and features/ instead of in eclipse/plugins/ and eclipse/features/).

From there, an individual “sitelet” (category.xml) is created for those jars. Unjarred features/plugins are jarred. The sitelet - a single update site category - is combined with other local sitelets & their associated jars into one composite update site. A digest is produced.

Rather than just pushing that whole site from the build server to the remote public server, I use a few tricks to avoid having to upload the same stuff over and over.

1. If the new site, which I’ll call the n^th release, or rN, is identical to the zeroth (current) release, r0, then the process stops right there, as there’s no point publishing the same bits again.
2. if rN != r0, we cycle the releases so we only ever have three of the same build’s branch (2.1.0) and type (S). r2 is deleted, r1 becomes r2, r0 becomes r1, and rN becomes r0.
3. Depending on the type of site, we w