Is running Eclipse on Raspberry Pi possible?

During the weekend I stumbled upon Bug 406749 Create native launcher and product export option for Raspberry Pi, which prodded me to do the long postponed task of contributing patches that has been used in Fedora to built Eclipse for arm.

My patches provide generic arm bundles. It is a part of the work. According to Fedora documentation, Arm processors exist in two versions -  software and hardware floating points. I guess that Eclipse built on one of them might not work on the other one, and it will be necessary to split each arm fragment in two.

It's also worth to consider if Eclipse on arm without FPU is really something we want - it will be unbelievably slow.

But straight to the point - I tested various amounts of memory assigned to maven for the purpose of Eclipse build - and it started succeeding only if maven was granted 900MB. That eliminates Raspberry Pi forever. Sorry for sad news :-(.

However, if you are interested in building Eclipse on various mobile devices, and you'd like to try out those patches, I'd be happy to hear the results!

And a small poll for the end (results can be found here, but please do the poll first!):


 

On the evilness of split packages in the OSGi

OSGi allows for having packages split across multiple bundles. This, together with a dropins mechanism, is a true mine field.

So, what's wrong with those split packages? They are split! OSGi, in some magic way, merges them during runtime, but does not see explicit dependency between bundles providing those packages.

The P2 reconciler app, using some Equinox service, refreshes all packages that have dependency changed. So, for example, if you install a bundle providing javax.xml into dropins, you'll have almost all plugins refreshed (depending on the dependency tree).

But, since bundles with split packages are not dependent on each other, you may end up in a not so much theoretical situation, were a bundle with one split package is refreshed, and the other is not. If they do depend on each other (f.e. one has an implementation, the other an interface) you will get a nice ClassCastExceptions or other, similar runtime errors.

Real Eclipse bug can be found in the Eclipse bugzilla.

DevCrowd'13 – share knowledge, share passion - impressions

I had a pleasure of participation in a conference called DevCrowd this weekend in Szczecin. And I must admit - I underestimated it, and got very, very surprised.

First of all, the conference, held at the Szczecin University of Technology was developer community organized, meaning there was no single, leading technology, solution, nor vendor.  This resulted in a really mind-blowing mix of speakers that touched problems on the border of many spaces (technical, human and legal one) and made many people to think about what they do.

Let me mention two really noteworthy presentation fragments:

• Adam Dudczak, "6 things that you were not taught during studies" discussed, amongst other things, the problem of choosing 3rd party dependencies for use in your project. This was a very right call in the era of social coding, and clearly outlined the need for IP management for communities that want to share their code.

• There were two talks by Jarosław Ratajski and Grzegorz Godlewski, related to web programming. Those talks resonated in my mind because they were about Java developers finding themselves in the JavaScript world, and giving a really strong message, that despite Web is somewhat inferior to desktop, it needs superior developers. I guess Netscape was wrong by targeting JavaScript "to nonprofessional programmers". 

 I realized apparently not so secret plan of OSGi and Fedora conquering the Java world and performed a brief introduction to it, and quite unexpectedly, found people who were really interested in migrating their applications.

I got totally convinced to small conferences, and I look forward next edition!

Maven groupId:artifactId and OSGi Bundle-SymbolicName - how they relate to each other?

OSGi massively coming to the maven world is a new trend, and is causing quite a big disturbance (at least to me).

First of all, as you already know, Fedora policies don't allow me to use binaries. Therefore Eclipse Orbit, a project that contains 3rd party Eclipse dependencies in the form of jars, is banned for me.

I witness that more and more open source jars support OSGi by default, but sometimes not exactly in the way I'd love to - especially if it comes to the naming schemes.

Let's look at the example of JDT core - the most widely used Eclipse jar. It was used as a maven dependency long before it received its official pom. As a result, it is available in Fedora with following aliases:

• org.eclipse:jdt.core

• org.eclipse.tycho:org.eclipse.jdt.core

• org.eclipse.jetty.orbit:org.eclipse.jdt.core

• org.eclipse.jdt:org.eclipse.jdt.core

The question is, which is the right one? Well, the OSGi Bundle-SymbolicName wiki page says that:

A BSN often takes the form of a reverse domain name. If automatically generated via Maven Bundle Plugin, takes the form ${pom.groupId}.${pom.artifactId}, or ${pom.artifactId} if it already starts with ${pom.groupId}.

So, in that case, we need to go the Maven Guide to Naming, and find out that:

groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. Look at More information about package names.

and

artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it's a third party jar you have to take the name of the jar as it's distributed.

The artifactId for Eclipse should be a jar name, which in turn should follow Eclipse Naming conventions. The groupId should be a reverse domain name of the project, so in case of JDT, we would get org.eclipse.jdt, thus the final and proper groupId:artifactId of JDT core is org.eclipse.jdt:org.eclipse.jdt.core.



The real problem will appear if the project does not obey Maven guidelines, and has groupId:artifactId commons-logging:commons-logging or junit:junit. In that case applying OSGI guidelines will cause invalid Bundle-SymoblicNames: commons-logging and junit, which are against OSGi guidelines, although based on them.

In this situation it would be good to reconsider group and jar name changes to reflect the organization domain:

• org.apache.commons:logging (logging.jar shipped)
• org.junit:org.junit (org.junit.jar shipped).

Happy renaming!