 |
| Exemplary history displayed in the History view. |
Thursday, May 9, 2013
Eclipse Mylyn - quite interesting feature
Did you know that Eclipse Mylyn integrates with a History view?
Unfortunately, it works this way for Red Hat bugzilla, but not for the Eclipse one :-(.
Tuesday, May 7, 2013
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:
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:
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.
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.
Monday, April 29, 2013
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!):
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!):
Wednesday, April 24, 2013
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.
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.
Monday, April 22, 2013
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:
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!
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!
Thursday, April 11, 2013
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:
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:
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.coreorg.eclipse.tycho:org.eclipse.jdt.coreorg.eclipse.jetty.orbit:org.eclipse.jdt.coreorg.eclipse.jdt:org.eclipse.jdt.core
A BSN often takes the form of a reverse domain name. If automatically generated via Maven Bundle Plugin, takes the formSo, in that case, we need to go the Maven Guide to Naming, and find out that:${pom.groupId}.${pom.artifactId}, or${pom.artifactId}if it already starts with${pom.groupId}.
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).
Wednesday, March 13, 2013
All roads lead to Rome
I'm a Fedora Packager. I (amongst others) take care about Eclipse in the Linux world. And one symptom of that care is prodding everyone else to update or drop dependencies. So, if your project suddenly gets a number of bugs open:
Today, I tried to address a bug opened not that long ago:
The said news is that ROME is effectively dead. The last comment from the project author is more than one year old. Project webpage offers 'Related searches'. The source repository does not contain a single tag. Their mailing lists contains spam traffic.
In a normal situation I'd just look for a replacement, but this case is different. There is NO replacement. It looks like a technology shift killed it. There's no need for a new version of RSS or Atom, so project matured and died.
Unmaintained library is a pain. It's a security hole. And will, sooner or later, damage the consumer. But what to do, if there is no alternative? Hope for the best?
- 398103: adopt latest jsoup
- 402882: relax requirement on lucene
- 398102: adopt latest jdom
- 398100: adopt latest org.apache.commons.lang
- and so on and so on...
Today, I tried to address a bug opened not that long ago:
- 398084: Adopt rome 1.0
The said news is that ROME is effectively dead. The last comment from the project author is more than one year old. Project webpage offers 'Related searches'. The source repository does not contain a single tag. Their mailing lists contains spam traffic.
In a normal situation I'd just look for a replacement, but this case is different. There is NO replacement. It looks like a technology shift killed it. There's no need for a new version of RSS or Atom, so project matured and died.
Unmaintained library is a pain. It's a security hole. And will, sooner or later, damage the consumer. But what to do, if there is no alternative? Hope for the best?
Subscribe to:
Posts (Atom)