Are you using Bazel as a build system and doing Java development? Do you want to give the Eclipse plug-in for Bazel a try?
I’ve spend the last couple weeks reworking most of the plug-in to better support Bazel development. It’s approach isn’t very different from the IntelliJ plug-in, i.e. it runs Bazel query and performs Bazel builds with aspects to obtain project and classpath information from Bazel. With that information it creates projects in Eclipse. It also uses project views (
.bazelproject) to configure what’s visible in Eclipse.
However, there are a few differences compared to the Bazel IntelliJ plug-in, which I’d like to highlight.
- It uses Eclipse projects to map targets so the classpath is really scoped to the classpath of the targets.
- It allows for some flexibility how targets are mapped to projects – you can have one project per target or one project per package.
- Because of Eclipse auto-build feature of individual Java source files HotSwap just works and is fast.
Documentation is here. The update site is https://opensource.salesforce.com/bazel-eclipse/latest/.
Oh and there is a preview release of a VS Code extension using the same feature to setup the Java Language Server in VS Code.
Last week, I started playing with the SWT macOS Cocoa port. You can follow all the changes and discussions via bug 502090. I now have a successful build using recent macOS libraries from 10.12.
The last missing piece is support for a Mozilla browser on macOS. This as been implemented using the XULRunner. However, the XULRunner is deprecated and has been removed from most Linux distros (according to Wikipedia).
I’d like to drop support for it completely from macOS. Is there anyone relying on it? If yes, do you have the time/resources to commit to maintaining it going forward?
Please comment on bug 506092.
Eclipse Neon is out. Time to give a long awaited feature a try again. It’s support for re-using the identify from ssh-agent running on my system within Eclipse. I want this primarily for the Eclipse Git integration.
As it turns out, the core support is part of Eclipse Neon. The SSH interface had been made extensible for additional identity discovery. The remaining missing piece is the actual code that bridges the ssh-agent connection into the Eclipse SSH interface (powered by JSch). The reason for this are – of course – legal issues. It would be great if those can be addressed and this can be shipped out of the box in Eclipse.
I forked the initial work from the JSch folks and made it consumable as an update site.
Please give it a try:
I’m using the Cisco AnyConnect Secure Mobility Client version 4.1 for connecting to a Cisco VPN. At some point, I noticed a significant speed drop. I don’t remember when it happened but I never got any speed higher than 50k bytes per second. That’s really slow compared to what my DSL allows.
The setup is pretty un-exciting: MacBook Pro ethernet via Thunderbolt display > Apple Time Capsule > GB switch > Fritzbox 3370 > DSL > Internet > Cisco Firewall.
After some further investigation today, a friend gave me a tip with regards to tweaking the MTU size. Turns out, Apple’s default of 1500 was actually the culprit. I didn’t expect that. My VPN is now working at full DSL speed.
Here is the link to testing and setting the MTU size: Fix WiFi on OS X by tweaking the MTU. Now, even thought the post talks about WiFi, it worked on my wired ethernet connection too.
Here is another example of why I love working with open source software and its communities. Last Thursday, one of my team members reached out and asked for advice with regards to a build issue he was observing. We use Maven & Tycho at Tasktop for building almost all of our products. One of its unique features is automated stable versioning based on source code history and dependencies.
Turns out that there was a shortcoming in the implementation with regards to building an aggregated version based on component dependencies. After finding out, I opened a defect report, prepared a patch and posted to the mailing list for awareness and getting feedback on Friday. This took me less then an hour of my time. By Monday – only 72 hours later – the patch was accepted and merged into the main code base, unblocking my colleague.
- Discover the root cause.
- File defect report
- Prepare patch
- Communicate about change and collect feedback
- Cross fingers – or – hold thumbs.
In my opinion, the key criteria for such a change being successful is the patch size. Yes, I could have added configurability to the change and that would have increased the patch size. The larger a change is, the more time committers need to set aside for understanding and reviewing a change. It’s about the minimal viable solution – keeping things simple. Don’t overwhelm committers with your first change.
Well, and it pays off going to conferences and having a beer or two with project committers.