Www.macrobug.com

[...] for a particular type of tool, across all platforms on all types of devices. Starting on Symbian OS was a good stepping-stone because the tool in question was more easily possible on Symbian OS, [...]

[...] The smartphone software market has been busy lately. Android comes along; Nokia open-sources Symbian OS; the iPhone becomes wildly popular. Ten years ago, Symbian was formed. It was the “open” [...]

[...] of open source projects using Mercurial is impressive – OpenJDK, Mozilla, OpenSolaris, Symbian OS – but they tend to be corporate efforts, and therefore aren’t likely to be trend- [...]

[...] some code inside Eclipse, which will need to perform all the interactions with your external code. Your ‘internal’ code has full access to al the Eclipse plug-in APIs. Ideally, the [...]

[...] to do. As before, organise your code into internal code which will run inside Eclipse, and external code which will run outside. But this time, you need a third thing: crossover code which will [...]

[...] and non-Eclipse parts of the process. But first of all, why? If you’ve got some code in Eclipse plug-ins that you wish to run from an existing Java system, your options are either to spawn a new [...]

[...] through them. So, the classes in such plug-ins are globally available to all other Eclipse plug-ins. Better still, Eclipse doesn’t attempt to load the classes in this plug-in… it [...]

[...] else – it’s fully extensible! (For the techies – all you need to do is define an Eclipse plug-in which does two things. First, you define certain ‘actions’ taken by different [...]

[...] a bit like some allege the GPL to be – a virus! It appears that, if any of your code is an Eclipse plug-in, the whole Java system has to be. Not true, it turns out! You can embed a whole Eclipse [...]

[...] of thing. This is called a ‘framework extension bundle’ (I think). This is a type of Eclipse plug-in which is an extension to the OSGi framework. The various classloaders running in the [...]

[...] plug-ins use their own class loaders (as explained in this excellent article). So, if your internal code returns a com.frangible.Sprocket, and your external code tries to cast that to a com.frangible. [...]

[...] code inside it. Specifically, here’s what you need to do. As before, organise your code into internal code which will run inside Eclipse, and external code which will run outside. But this time, you [...]

[...] are probably going to be the way of the future… PS it will be interesting to see what the Symbian Foundation does for this sort of thing. [...]

[...] ! I can’t wait to see how easy or hard it is, in practice, to get changes submitted to the Symbian Foundation… [...]

[...] : the openness of the APIs, and the degree to which the code is open source. Again, the Symbian Foundation is pushing the envelope. On both counts, it is in principle more ‘open’ than any of the [...]

[...] ’ and ‘external’ code should be minimal, since it’s tricky. Create a new Eclipse plug-in project. This will house your ‘internal’ code. Let’s assume we’re going to call [...]

[...] structures that need to be accessible from the internal and external code. Create a new Eclipse Plug-in Project for this crossover code. Create classes, etc. inside that plug-in. Now the clever bit: [...]

Eclipse is a great plug-in system for Java. But superficially, it appears a bit like some allege the GPL to be – a virus! It appears that, if any of [...]

In Part One I explained how to start up a whole Eclipse/OSGi plug-in system from a normal Java application. This worked fine, except there was no way [...]

[...] with your external code. Your ‘internal’ code has full access to al the Eclipse plug-in APIs. Ideally, the information exchange between the ‘internal’ and ‘external’ code [...]

[...] environments such as Python. Even before the Foundation move, it could be argued that the Symbian APIs were more open than the Android ones. Symbian and Nokia have jumped through a lot of hoops to [...]