As mentioned in my previous post ... Ganymede has this new worthy feature wherein you can browse to the contribution id for a view, perspective etc ... But Y should only the Ganymede Users have all the fun ... Thanks to Prakash, my friend for invoking our team at ANCiT to write a small plugin contributing a search page to search for ids in 3.2 and 3.3 version of Eclipse.
A Page has radio buttons to select which ID you want to search .. And then you can right click on th desired ID and copy it to the clipboard. Then paste it in your perspectiveFactory code or in your perspectiveExtension extension point or wherever required ...

Thanks to Prakash Anna again .. Now thats how we call him ... We have hosted this project on http://code.google.com/p/search4contributionid and its all available for download ... Please utilise this and let us know if you like it ... We plan to join the band and publish lot of utilities as our contribution to the eclipse community ...

Nokia, together with Sony Ericsson, Motorola and NTT DOCOMO has announced that they will form an open source foundation to host the Symbian OS development.  In order to enable the Foundation, Nokia plans to acquire the remaining shares of Symbian, that Nokia does not already own and then contribute the Symbian and S60 software to the new open source foundation. The open source Symbian Software is intended to be released under EPL.

There have been a number of questions in eclipse.newcomer lately about the availability of a visual editor for Eclipse 3.4 Ganymede.

So, I thought I'd see if VE 1.3 can be installed into Ganymede using p2 -- and in fact it's pretty easy to do.

As noted in VE Installation Guide, you can use the "Eclipse IDE for Java EE Developers"... but because I usually run with the Eclipse SDK, rather than an EPP bundle, I wanted to know what the minimum requirements are for VE, so I unpacked VE into Eclipse's new dropins/ folder, and started Eclipse with the OSGi console active, using this script:

#!/bin/bash
workspace=/tmp/workspace-clean-34
pushd ~/eclipse/34clean >/dev/null
if [[ $# -eq 0 ]]; then
        rm -fr eclipse $workspace emf-unpacked
        eclipse=eclipse-SDK-3.4-linux-gtk.tar.gz
        echo "Unpack $eclipse...";
        tar xzf $eclipse
        ve=org.eclipse.visualeditor-1.3.0.200709121813
        echo "Unpack ${ve}.zip into dropins"
        unzip -q ${ve}.zip -d eclipse/dropins/ve
        mv eclipse/dropins/ve/$ve eclipse/dropins/ve/eclipse
fi

vm=/opt/sun-java2-5.0/bin/java
echo "Using vm=$vm and workspace=$workspace"; 
./eclipse/eclipse -vm $vm -data $workspace \
  -consolelog -clean -debug -console -noexit -vmargs \
  -Xms128M -Xmx256M -XX:PermSize=128M -XX:MaxPermSize=256M
popd >/dev/null

What I found was that the console listed all the missing dependencies for the VE feature, making it easy to find the features I needed to install to fully enable VE. I fired up the Help > Software Updates and installed the following from the Ganymede Update Site:

On restart, I had a working visual editor:

There’s something about the Java Forum Stuttgart conference that I really like. The conference is a little on the large size (I believe that I heard that there were 1,200 attendees) which gives the exhibit area a really busy feel. Good busy.

As a speaker, I can’t say enough about this conference. They take care of us. Every year they get us great gifts. The best part is that the gifts tend to have some local tie-in. This year, they gave us coffee and tea from local providers. It came with a little booklet that, if I could read German, would tell me all about the company and how it is a cornerstone of the Stuttgart business community. That personal touch is nice. It also helps that they assign me my very own personal assistant (who I assume is the very own personal assistant for a couple of other folks). This year, she remembered my Modelleisenbahn hobby and had a map ready for me pointing out the locations of local stores.

My talk went very well. I presented Mylyn to a standing room only crowd (apparently there were about a dozen people in an overflow room). Here’s what they looked like from my perspective.

I decided to mix things up a bit this time through and started with a demo. I went out on a bit of limb and just started implementing part of the solution for bug 237658. The first thing I did was create subtask for this bug. With Mylyn 3.0, new tasks (or subtasks) can be created for a repository without actually submitting them (which was handy as I didn’t notice the Ethernet cable which I’m sure would have given me Internet access if I had thought to try it). So I created the subtask and just started into changing the Expenses (EBERT) application to channel change events through the Equinox event framework. I plan to submit the new subtasks to Bugzilla and check the code into a new branch sometime soon (I’m feeling a little lazy right now).

I asked the audience to try not to get too taken by the Equinox stuff and focus on the task-oriented development process (I really did want to get them thinking a bit more about Equinox and the Examples project). In the process, I managed to show off the Bugzilla integration, and the Über-cool context-based filtering. I wrapped up with a quick pass through the slides to reinforce what I demonstrated. The net result of the demonstration was the same as last year: I felt like a rock star. People love Mylyn.

One of the disturbing take-homes from the session is the number of developers who apparently do not use an issue tracking system of any form. Mylyn supports, Bugzilla, JIRA, Trac, XPlanner, CodeBeamer, and more. But there were a lot of questions about how Mylyn can be used to share tasks without a repository (I showed how you can drag tasks out of the Task List view onto the file system and then from the file system into a different workspace’s Task List; I guess that works).

I rounded out my week by talking about Ganymede with two different audiences. The first audience got to listen to me two hours after I got off the plane. It was not one of my best performances. The crowd today in Zürich seemed to have had a better time; clearly a few extra hours of rest make big difference.

I leave you today with a picture I took of Doug Clarke from the EclipseLink project from last night’s Stammtisch.

It’s good to be king.

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.

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?

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.

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

I am a bit frustrated right now. Last week I installed Eclipse 3.4 and I thought, now it is a good time to give Subversive a try, since it is the “official” subversion client now. I am using Subclipse for years now, and it was working very well and smoothly til today. Here are my experiences using Subversive with Native JavaHL connector (Eclipse 3.4 on Windows Vista together with an existing Subversion repository):

• I destroyed accidentally the src/* directories of many of my projects in the trunk of my subversion repository. I don’t know what I did wrong, because on the client-side everything looked fine to me (And I did exactly what Subversive recommends about reconnecting svn working copies checked out with another client). I only realized the deletion of the source folders when I wanted to check out the projects from another machine. I googled about that strange behavior and found out that I was not the first one who destroyed the src directories…
• Then I fixed the repository from a recent tag, and checked out all projects into a clean workspace using Subversive. Now I am having problems with the bin directories. I don’t know why, but Subversive thinks that some of my Java files are in the bin directory on the server, but of course they are not. I got error messages like: org.eclipse.team.svn.core.operation.UnreportableException: 0×00000004: The resource is inaccessible: /com.siemens.ct.mp3m/bin/com/siemens/ct/mp3m/PropertyTester.java. When I open the synchronize view I also see Java files in the svn repository’s bin sub-directory (which don’t exist in the repository)

Probably I just don’t use Subversive the right way or I should try another connector, but right now, I want to switch back to Subclipse. I am wondering if others have similar experiences using Subversive + native JavaHL and Eclipse 3.4 on Vista. Or, I would appreciate any tips how to make it work like I would expect.

The first edition of Eclipse DemoCamp in Krakow was a spectacular success.

The room was full ;) ...



... people could see some new trends in technology ...



... and everyone was happy.



Read more about the event and see more pictures.

Hi,

I just work on some new icons for Eclipse SCA project.
I need some comments to choose which one need to be removed or changed.

On my point of view, it will be nicer than the v1.0 version because it will better fit Eclipse UI and icons style.

New global palette:

SCA Bindings:

SCA Implementations:

SCA Interfaces:


The new tree Editor:
The graphical Designer isn't ready because it uses old style for embedded icons.
For comment, you can use this bug report.

Lots and lots has already been told about the Common Navigator framework. I'm not going to add any more explanation about the framework, but will tell you a tip on how to easily create one with the Workspace resources as the default contents.

Open your plugin.xml and go to Extensions tab. Click on Add and select the Extension Wizards. Select 'Common Navigator' and click Next.


Configure the options and press Finish.


You are done. Can it get any simpler than this?

In case you didn't find the Common Navigator in the list of Extension Wizards, you may want to download the Cypal Eclipse Utils and drop the jar into your plugins/dropins folder.

For those who are interested the background:

Few days back, I was working on creating a Common Navigator for an RCP application. Just like most of the RCP apps out there, I want to start with Workspace resources first. It didn't work as expected. I spent around 30 mins debugging only to find out that I've missed the "org.eclipse.ui.navigator.resources" in the dependencies. That is when I thought how good if some has already implemented a template for this extension. Instead of complaining, I thought why not to create on. Less than an hour of hacking existing PDE Extension Wizards, the base code was ready. Another half-an-hour at Google Project Hosting, the download is ready to serve. Thanks to PDE guys and Google for making things much simpler.

I plan to add few other handy utilities like this. Let me know the usefulness of this one.

I have been getting to know JFace Databinding lately. It was on my TODO list of Eclipse technologies to learn and although things were rough in the beginning, I'm starting really appreciate things. For example, I had a use case where I was binding a value to a text control. By default, the model was being updated on every keystroke which could be fine. However, if you have a complex UI that does fancy validation, it can cause unexpected results like refreshes that you just don't want. A simple and more natural thing is only to commit a change to the model after the user is done typing instead of every keystroke. The solution in JFace Databinding is simple...

SWTObservables.observeDelayedValue(400, myObservable)

There's also a nice code snippet that you can run to see how the code works.