rgrunber

Get To Know A Command : jdeps

Well time sure flies. I can’t believe I haven’t made a post since the end of last year. It’s been quite busy these past few months but I’d like to think I haven’t completely dropped off the map in terms of Fedora contributions.

Today I’d like to talk about ‘jdeps’. It’s such an awesome tool for helping visualize dependencies. A little while ago I needed to convert about 30 Java packages to proper OSGi bundles (with proper Import-Package statements) and this tool really simplified the task.

mvn -DincludeScope=runtime depdendency:copy-depdendencies
jdeps -dotoutput=result/ target/dependency/*.jar

If you only care about dependencies at the jar level (using Require-Bundle), then you can even add a ‘-s’ flag to jdeps. The tool is part of the Java OpenJDK Development package (eg. java-1.8.0-openjdk-devel) shipped within Fedora.

As an example, it was quite easy to generate a nice dependency graph of the java library docker-client.

Improving Eclipse Platform Stability On Rawhide

The Eclipse platform on Fedora Rawhide can be pretty unstable at times. Every update to one of its dependencies requires a rebuild. As a result, it has been on our TODO list for a while to work out some way of making Eclipse more resilient to these kind of dependency updates (at least in cases where a rebuild shouldn’t be required). Looking upstream, there are quite a few bugs relating to this topic (410710, 410785, 408138) .

For simple rebuilds where project metadata likely hasn’t changed there’s fix for symbolic links in place.

Another common breakage happens when dependencies that are listed as plugins within a feature get updated.

Unlike regular Eclipse plugins that might contribute certain capabilities, a feature represents a set of plugins. One can think of them as RPM meta-packages and some features are used especially by end-users to install a larger set of plugins (eg. org.eclipse.cdt.feature.group is “C/C++ Development Tools”). A feature lists the set of plugins it provides with the <plugin> tag and may also specify dependencies with the <requires> tag. The difference is that the <plugin> tag locks onto the exact version discovered at build time, and may only resolve against that exact version. The <requires> tag on the other hand allows you some flexibility in terms of dependencies with ranges and some compatibility levels.

Sometimes one might see features listing dependencies as content. Does the JDT provide, or own org.junit and org.hamcrest ? Do we really mean to say that changing the versions of those plugins implies a completely different feature ? Clearly this isn’t the case, and it would make much more sense to use <requires> but the former practice seems quite common.

I don’t think this is done out of lack of understanding, but because projects also want to include their dependencies into the repositories they deploy. The <plugin> definition accomplishes this. Using <requires> one would also need to list the plugins to be included in the repository definition (site.xml/category.xml) and some platform projects have to jump through some additional hoops to change this file so it’s not a huge surprise that many go for the simpler option. Sadly, this causes some problems for us in Fedora land.

Luckily there’s now fix for platform features that should help reduce the number of rebuilds.

Common Mylyn Data Across Workspaces

I used to have a lot of projects in a single Eclipse workspace (~500), and after a certain point it became really difficult managing all of them at once. I already had them sorted into working sets but even having to constantly open/close them was a bit too much. As a result I decided to split these various projects over a few workspaces.

Now I had a new problem. All of my Mylyn Tasks (Bug Repositories/Queries) were configured for my original workspace, and that metadata was all under that workspace’s main directory (this is the default). I didn’t want to be constantly switching to my main workspace just to get bug updates, or make changes, so it’s nice that Mylyn’s data location is configurable (Window -> Preferences -> Mylyn Tasks -> Advanced).

mylyn-tasks-dir

Simply copy over your task data from $WORKSPACE/.metadata/.mylyn to some common location, and set that to be your data directory for each of your workspace preferences.

Follow

Get every new post delivered to your Inbox.