build2be/com/e something is going on over there

A new version can be found on the update site. The new versions of the features contain the latest fixes. New in this version is support for Jasper reports which are so far used by Bioclipse Decision Support and Bioclipse Brunn for generating printable reports.To update go to Help -> Software Updates... and select the features you want to install.Known problem: The splash screen erroneously shows version number to be 2.4.0 after update. (Technical information can be found at bug: 2084 in our Bugzilla)

I’m embarking on a pet project, in short: a Python-based web application using my favourite editor, Eclipse. Being quite new to this, I thought I would poll my readers, especially those Eclipse web app developers among you, for their opinions on the best solutions. I realise I’m giving very few details, but I simply want [...]

In my previous post on “OSGi Compliance”, I discussed the idea of making libraries ready for OSGi without depending on OSGi directly. In light of BJ’s comment I will refer from now on to OSGi “Readiness” rather than Compliance, as the latter term is easily confused with the concept of a framework implementation that complies with the OSGi specification. In each of these blog posts, I will state a requirement and then look at options for satisfying that requirement in an OSGi Ready way. Problem Statement You are developing a Java library, “Framework X”. Occasionally you must load and instantiate a class dynamically by name, where the name may originate from a configuration file or be passed into the framework as a parameter to an API call. You would like the framework to work cleanly both in OSGi and other environments, i.e. there must be no dependency on OSGi. For example, suppose we are implementing an O/R mapping framework similar to Hibernate, and the user has supplied a configuration file such as the following: This tells our framework to create an instance of org.example.domain.Event for each row of the EVENTS table. Therefore we must dynamically load and instantiate the org.example.domain.Event class. Discussion To dynamically load a class in Java we require two things: the fully qualified name of the class, and a ClassLoader from which to request it. If we have both of these then we can trivially load a class irrespective of whether we are in OSGi or not. To reiterate: OSGi does not interfere with the standard Java class loading API. If we have the fully qualified name of a class and a ClassLoader that knows of that class, then we can always load and instantiate the class. Problems arise only when we do not know the correct ClassLoader, and make the wrong guess about which one to use. First Wrong Guess: Class.forName() Java provides us with a way to load a class without explicitly specifying a ClassLoader, using the single-argument version of the Class.forName() method: Class clazz = Class.forName("org.example.domain.Event"); Since we don’t specify a ClassLoader, this method uses the loader that loaded the class in which the line of code appears. In other words, it uses the same loader that loaded the framework. In a traditional Java SE environment this usually works just fine, because both the framework and domain classes are probably installed as JARs on the classpath, and the classpath is loaded by a single ClassLoader, the so-called “system” loader. But in OSGi, the domain classes are likely to be supplied in a different bundle, because there is a clear modular separation between the O/R framework code and the domain model classes, and therefore they will be loaded by a different ClassLoader. We can still make it work if the package org.example.domain is listed as an import of the framework bundle like so: Import-Package: org.example.domain, ... However this is unsatisfactory because Import-Package is statically defined, and a general-purpose O/R framework does not know in advance which domain packages it will need to import. (NB there are a couple of other workarounds for this problem in the case that the framework code cannot be changed. These include: DynamicImport-Package; shipping the domain classes as a fragment hosted by the O/R framework; and using the Equinox-only “buddy loading” feature. However all of these workarounds have their own severe problems, which I shall not discuss in depth here because the purpose of the post is to document how to best implement a framework such that hackish workarounds are not required.) Second Wrong Guess: Thread Context Class Loader The Class.forName() approach fails not only in OSGi but also in other environments such as Java Enterprise Edition, for similar reasons. Because of this, another common pattern is to use the Thread Context Class Loader (TCCL), which was introduced relatively recently (i.e. Java 1.2): ClassLoader tccl = Thread.currentThread().getContextClassLoader(); Class clazz = Class.forName("org.example.domain.Event", true, tccl); Some libraries use the TCCL exclusively, others use it as a last resort after failing to load from other candidate class loaders. Almost every library follows a different strategy because Java has provided almost no specification or guidance on when to use the TCCL… to quote a classic JavaWorld article: Those class and resource loading strategies must be the most poorly documented and least specified area of J2SE. Even in J(2)EE the specifications do not lay out precisely which set of classes should be visible through the TCCL. In practice, a J(2)EE application server is able to provide a sensible set of classes via the TCCL because the programming model is highly constrained: each application runs in an isolated silo, is not allowed directly to create threads or network sockets, and threads cannot cross application boundaries. Because it controls all the entry points, the application server can provide a TCCL that is appropriate for the running code. OSGi’s programming model is far less constrained. Bundles are free to create threads, to open network sockets, and to call APIs exposed by any other bundle. There is no way in Java to intercept a direct method call that happens to cross a bundle boundary, so the OSGi framework cannot ensure the TCCL is relevant to the current code. As a result, the TCCL is not defined by the OSGi specification, and it may be null. Therefore, we cannot rely on the TCCL for anything. Solutions Now let’s discuss possible solutions. To be clear, all of the following suggestions are intended to supplement rather than replace existing approaches. If your framework is working in J2SE/J2EE with Class.forName() or TCCLs then you should continue to use those approaches. But, please provide additional options for runtime environments such as OSGi where those approaches fail. If you feel these suggestions are trivial or obvious — that is exactly the point. There is nothing complicated about making frameworks that work well in OSGi. Indeed, you may find you prefer using one of these patterns as they reduce the complexity and testing burden of your code. Option 1 — Instance Factory The first option is to avoid dynamic by-name class loading altogether. Although not always practical, it may be possible in some cases to allow clients to supply their own callback or factory to create objects as required. For example our O/R mapper could define the following interface: public interface DomainObjectFactory { Object createInstance(String tableName); } Clients could supply an instance of this factory when initialising a session, or we could wire it in with our favourite Dependency Injector. This has the advantage that clients can construct objects however they like, rather than placing restrictions on the permitted constructors in the domain classes. On the other hand it may be risky since a client factory implementation could return shared instances, whereas the framework expects new objects on each call to createInstance(). So long as such requirements are documented, the framework should permit clients to do what they like. Option 2 — Register Classes Another option is to add API for clients to register loaded classes in advance. This is best illustrated in client code: session.registerClassForTable("EVENTS", Event.class); List events = session.createQuery("from Event").list(); Here the client code has direct visibility of the Event domain class, so it can use a class-literal to pass a Class to the framework API. The framework can now use the supplied class whenever it reads from the EVENTS table. We can even register classes directly against their names: session.registerClass("org.example.domain.Person", Person.class); The framework can use the registered class whenever it needs to create an instance of org.example.domain.Person, but fall back on Class.forName()/TCCL for unregistered names. No other changes are required in the framework. Note that with this option, the client loses some flexibility and control. By passing a class rather than instances, the client has no opportunity to construct objects in the way it wants them, but instead relies on the framework to construct them. This is not so bad in the running example of domain objects, but suppose we are talking about some kind of “service” object. Without control over instantiation, clients cannot make the service aware of its “environment” or “context”. Sometimes this forces us to use static fields, thread-local variables or other hack to get hold of our “context” after having been instantiated by a framework. If the framework allows pre-instantiated objects, then those objects can be pulled out of the OSGi service registry, a Dependency Injection container, or even generated on the fly. So when designing an API, please consider whether the framework really needs to take control of instantiation by requiring Class objects — if not, at least allow the option of passing pre-instantiated objects. Option 3 — Pass the Loader This option is the conceptually the simplest, and also has the least impact on existing code: allow clients to pass a ClassLoader into your API. The appropriate time to do this is highly dependent on the nature of the API, but in the O/R mapper it might be done during initialisation of a session: SessionFactory.createSession(MyClass.class.getClassLoader()); // ... OR ... session.setDomainClassLoader(MyClass.class.getClassLoader()); To minimise the impact on existing code, this method can be overloaded with another version that takes no argument. Alternatively, clients could pass null to indicate that the framework should attempt to find the right ClassLoader. Again there is a loss of flexibility for clients since this solution assumes all classes can be loaded from one class loader, which may not actually be the case, but in practice it doesn’t create any real problems. Summary Although this post has been rather long-winded, the message is very simple: stop guessing. If you are writing a library that performs dynamic by-name class loading, do not make assumptions about which ClassLoader to use. Allow client code to specify a class loader, or perform its own class loading. By all means retain your Class.forName() or TCCL-based lookups, but please provide an override for environments in which they will not work.

In our digitization wiki project based on Eclipse 4 and Scala it was time to find a persistence solution. As a quick overview of what it’s about, our app will basically allow a user to edit a digitized book page, showing the original scan as an image, with the selected word highlighted. It currently looks [...]

When we last left our erstwhile travelers (that would be all of you) they were surfing the quantum wave on their way to a future refactoring of their past to allow them to simultaneously feel proud of their work and embarrassed that they were following some guy who is making it all up as he [...] 2010-08-29T23:25:16Z cvalcarcel

There was a long time no update from my side. Mostly because of my new full time project. Another reason was - I've played a bit with different Linux distributions. Finally I've decided to move to Mint (based on Ubuntu). This is a great distribution which is far easier to manage as Windows XP, even for complete beginners. I've also tried Windows 7, but it was not really better then XP except that it can address now all 8 GB of RAM I have in my PC. From the administration point of view, I found Mint (Ubuntu) much easier. So why this post? After switching to Ubuntu, first think I've stumbled upon was the HUGE toolbar size used by Eclipse. Horrible. So I had to tweak my GTK themes and also one of my plugins, to get this toolbar's to the proper dimensions. May be more about this later (I've patched one of Murrine themes), but as a result, I've released a new 1.5.6 version of the Extended VS Presentation plugin. Additionally it has a bugfix for the maximize/minimize actions which were not properly working on Linux in some cases. Enjoy. 2010-08-29T21:41:53Z Andrei Loskutov

There are rumors that Xtext does only have rudimentary support for language libraries or language reuse and does not allow to create 'advanced stuff'. And it is actually true, that Xtext has only first class support for extending only one other language. But with some creativity and customizing, it is easily possible to create really nice editors for intermixed languages. I've produced a small screencast that demonstrates how an editor for template proposals (read: a template language) may look like when it's aware of your target syntax.Besides the smart editor for template proposals there is another interesting feature in this screencast: As template proposals are usually edited on a preference page, I implemented a small prototype that shows how a form field may leverage the features of a full blown Xtext editor.Both prototypic implementations are only based on Xtext 1.0 APIs and not yet publicly available. But I'ld assume that at least parts of them will be moved into the Xtext Indigo stream. Stay tuned!

IDE Innovation Every now and then some folks report that the IDE they’re developing now supports this or that cool new feature. Sometimes I envy them for such progress - but more often than not I end up realizing that the OTDT already has that feature or something very similar. Is that just my personal bias [...]

Hi there, In the context of an IResourceChangeListener I need to modify a given preference file in the workspace.  Because of “Note that during resource change event notification, further changes to resources may be disallowed.” the only solution to perform this change is to delay it on a future event (5 seconds later, on the [...]

If you would like to search in eclipse forum, here is a quick form which may help you.Project name:Your search:

Some of you may have noticed the debate happening regarding proper entry expectations for WTP incubator project following Holger’s veto of a committer election. Holger is acting well within the power granted to him by Eclipse Development Process (EDP), but is it a right and proper action? Every committer on a project has the veto power in an election. By extension, any entry criteria for a project (whether written or unwritten) is nothing more than a social convention. The reality is that every committer can choose to levy their own personal expectations. Most of the time it’s not a problem, except when it is. Here are some quotes from this particular event: “I found only some bug reports but not a single code contribution from any of the four nominated persons. Please attach the planned code contribution to a bug report. I'd like to vote for each of the nominated persons as soon as I know that the code is readable and covered by JUnit tests.” “Have [snip] been asked if they like to become committers as individuals (and not only as employees of SAP)? Are these authors of the code or what is their motivation to maintain and enhance these editors?” In a regular project with established code base, established team and well-defined scope, you can argue that giving every committer veto power over elections is appropriate. After all, there is an established code base to protect. The same considerations do not apply when a new component is proposed in an incubator. The WTP incubator project was started with the intention to provide a low entry barrier playground for people to come and experiment on new ideas while gaining experience and proving their merit to committers on the core projects that will eventually be asked to admit matured functions. Incubators make sense because they provide a quicker way to get started than a separate project proposal. Unfortunately incubators have to rely on a social convention that existing committers act in a welcoming fashion to newcomers. Most of the time that happens, except when it doesn’t. I would posit that there is no legitimate purpose served by holding a committer election when a new component is proposed for an incubator. The situation is supposed to be very similar to new project creation and we don’t hold elections there. The party proposing a project gets to designate a group of individuals to be the initial committers without anyone questioning their credentials or motives. A similar process is needed to make incubators work better. The last revision of EDP has formalized the concept of a persistent incubator. I propose that we build on those revisions and amend EDP to remove the committer vote requirement for incubator projects when a new component is being proposed. The project’s PMC would still have the oversight and ability to decline a new component proposal. This change would also fix the rather awkward problem of having to have “seeder” committers when creating incubator projects. Note that my suggestion is for persistent incubator projects rather than normal projects during incubation phase. I am also not suggesting that we remove committer vote entirely from incubators. Anyone wishing to join existing effort already underway in the incubator should still be subject to committer vote. Thoughts? PS.1 : This situation has served to highlight a process problem and it is the process that I seek to improve. I have no beef with Holger. I am sure he is acting on what he believes in. PS.2 : I am further confident that this particular storm will blow over, Holger’s objections will be met, another election held, etc. That doesn’t mean we shouldn’t try to improve the process so that such situations do not happen again and we continue to have vibrant incubator projects at Eclipse. Update: At Wayne’s request I created a bug to track this proposed improvement to Eclipse Development Process.

I have the pleasure to present Xtext in two of the most beautiful european cities within the next two weeks. Belgian Eclipse Community Meeting (Antwerp)I'll be in Antwerp next Tuesday and meet up with Belgian's Eclipse Community.The event is free of charge and the details can be found here. There's also a presentation of EGit, which I'm looking forward to see (I'll have lots of questions :-))."Developing Domain-Specific Languages with Xtext" (Stockholm)A week later on Thursday, the 9th, I'll be in Stockholm. The event is sponsored by Jayway and there will be two presentations. First I'll talk about Xtext and afterwards Patrik Nordwall and Andreas Källberg will present Sculptor, which is an open-source framework/code generator based on textual DSLs implemented in Xtext.The event is also free of charge. Register here.

Glyn Normington (VMware), Steve Powell (VMware)   Abstract: The Eclipse Virgo project provides a modular open source application server based on OSGi. The project is a donation to the Eclipse foundation of the dm Server open source project developed by SpringSource (VMware). Virgo provides a standalone kernel which may be used on its own or configured to create custom server types. Virgo Web Server integrates the Gemini Web container on top of the kernel to support standard WAR files and modular webapps comprising OSGi bundles. In this webinar, we'll explore the key features of Virgo such as: repositories, deployment plans, regions, Equinox console extensions and administration console. We'll demonstrate the Eclipse-based tooling and the runtime facilities of Virgo. We'll also cover the current status of the project and how you can get involved. Total running time will be approximately 1 hour 8:00 am PDT / 11:00 am EDT / 3:00 pm UTC / 5:00 pm CEST - Convert to other time zones Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar. delicious | digg | dzone 2010-08-26T13:22:12Z EclipseLive lynn.gayowski@eclipse.org

I have been checking out developer.force.com this week and it is a pretty extensive cloud based solution for developing, deploying, and using applications in the cloud.  I checked out their Eclipse based development videos and the development environment looks pretty comprehensive.  I would like to hear if anyone who reads this blog has any real [...]

Today I vetoed the nomination of five potential committers. This is something I really disliked and hated doing but I believe I had to: all five nominated persons have reported a few bugs but have not (yet) contributed a single patch. They have been nominated because the company they work for is going to contribute [...]

I learned from Steffen Pingel and Ekkehard Gentz that M [...]

What would you build into *your* perfect Android tablet? Find out my choices (and argue with them) in this continuing series.

UPDATE: an update site including Jin’s GSoC work is now available. I was lucky enough to be the mentor on a Scala IDE for Eclipse project which was selected for this year’s Google Summer of Code. Jin Mingjian was the student for this project, and it’s been wonderful to work with him over the last few [...]

I've been working hard these past weeks in my evil secret lair. Well, maybe not so secret, given that the results are, in true open source fashion, open: 323050. But it's definitely evil: among my tasks this week has been rejecting 6 out of every 7 Eclipse Summit Europe modeling submissions. I'm sure no one will take it personally and I'll remain ever so popular. Not! In any case, I'm taking to the clouds today!That's right, I'm headed for Google's headquarters, with my brand new passport anxiously awaiting its first stamp of approval. (Did you know that a trip through the washing machine will launder all evidence of ever having been to the states?) It's Eclipse Day at the Googleplex where I'll be unveiling my master plan: world domination for Eclipse Modeling. Resistance is futile. Expect to be assimilated soon.

After working on the Riena framework for nearly a year now, together with some colleagues I am challanged to use Riena to build a small Client Server Application for our team. I never thought what a refreshing eye opener this can be from time to time. It is one thing to sit in your closed [...]