rgrunber

Sharing directories over a network with sshfs

Occasionally, you may find yourself in a situation where you need to access files from another machine on your network. As an example, I use Eclipse Mylyn for managing a large amount of bugs I care about, across various bug tracking systems. I keep this data in one central location and it’s simple enough to share across Eclipse workspaces on the same machine. But what if you want to access that data from another machine ?

In cases where things haven’t been set up ahead of time to allow for NFS (and to be honest, I haven’t really used NFS in a while) one can get away with using SSHFS (an already running SSH daemon seems more common). However, if the network is already trusted, then encrypting that data is just slowing things down. Although we can’t disable encryption outright, we can certainly optimize for speed by choosing a fast cipher.

For the purpose of this post, we assume that both machines communicate over a trusted network.


$ sshfs -o Ciphers=arcfour -o Compression=no user@192.168.122.2:/data/mylyn-data /tmp/mylyn-data

From here, we can pass /tmp/mylyn-data as the task directory for Eclipse Mylyn.
If you ever find your ssh connection has been improperly terminated while the mount point was active, one might need to issue the following command to properly unmount.


$ fusermount -u /tmp/mylyn-data

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.

Follow

Get every new post delivered to your Inbox.