The most significant feature of Kepler Eclipse on Fedora

Yeah, I know I'm kind of repeating myself, but look what happens after you update Eclipse in Fedora 19:

Eclipse after update in F19

P2 discovers that you're system installation had been changed, finds what you have installed as a regular user, and then asks you to install those things again, providing you a nice wizard:

Features reinstallation wizard page

This is a big step forward since previous Fedora releases, where Eclipse package update caused a loss of user installed features, or even totally broke the installation.

Of course, not only Linux will benefit from this approach, but all setups, where users have only read-only access to a master installation administered centrally.

Edit: Things never go as smoothly as one would wish. The problem that I was having with this dialog was that when I had multiple Eclipse installed, from time to time, the dialog was trying to reinstall things from "wrong" Eclipse installation.

It turned out to be a feature, not a bug. Eclipse, when shared install is run for the very first time, tries to find previous installation on the best-can-do basis. This scenario is a bug for Fedora, because Fedora Eclipse has only one location that does not change, and therefore if there is no local configuration for that location, it means that nothing should be reinstalled. I think a solution is as easy as setting this property to the Fedora installation:

-Declipse.p2.skipMovedInstallDetection=true

Eclipse Mylyn - quite interesting feature

Did you know that Eclipse Mylyn integrates with a History view?

Exemplary history displayed in the History view.

Unfortunately, it works this way for Red Hat bugzilla, but not for the Eclipse one :-(.

Eclipse Marketplace Client just got updated in Fedora 19+

Short introduction for my Fedora audience:

Eclipse Marketplace is, well, a market for Eclipse plugins.  Eclipse Marketplace Client is a tool that allows for browsing and installing plugins from within your IDE. The analogy to other application stores is quite obvious. You can install the client by invoking:

sudo yum install eclipse-mpc

Main content:

Fedora 19 release date is approaching us fast. Since the Fedora release and Eclipse release are very close to each other, and there is a freeze between the RC (Beta) and the final release, I'm updating now the Eclipse stack to the Milestone 7 - the last milestone between the final release of Eclipse.

Going from one project to another I stumbled upon Eclipse Marketplace Client. It has no new release scheduled on it's website, but the log has revealed quite interesting features, so I've decided to include those updates.

Here is a screenshot of a new Marketplace Client:

Note new attributes that are now displayed - the number of installs and favourites stars. This will definitely help to assess which solutions are well tested in the field :-).

It also looks like there will be a newsletter in the marketplace client :-)

The market place is interesting also from another point of view.  I have written a small utility mojo that transforms a p2 repository/update site into a runnable form that could be put in dropins. So the part of rpm responsible for installing the client looks like:

mvn-rpmbuild org.fedora:feclipse-maven-plugin:install  \
 -DsourceRepo=org.eclipse.epp.mpc.site/target/site -DtargetLocation=%{buildroot}%{install_loc}/eclipse

Which is a great progress from manually unzipping features into destination :-).

Yes, yes, I'm aware that dropins mechanism is not really the best solution, but that's the only solution that we managed to get work together with rpm.

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!