Kichwa Coders are proud to be a gold sponsor of Pydev. For us this is a continuation of the support we pledged last year. This year has also seen Kichwa Coders join the Eclipse Science Working Group and become part of the global collaboration working towards reusable open source software. Python has always played a major part in scientific software and will continue to do so going forward. PyDev is the best Python development environment out there, we love it and our clients and their customers love it. We’re excited about the plans ahead, particularly the Python profiler. Here’s where you can learn more about the new features planned and join us in supporting PyDev.
Dawn Developer Workshop, June 2014
This year, the 2-day DAWN developer workshop had an added dimension as the first day was an Eclipse Science day. It was well-timed and coincided with the formal creation of the Eclipse science working group which is growing a community around Eclipse and scientific software development. Diamond Light Source played host and the day included a fascinating tour of the guts of the synchrotron (once we made sure it really was turned off). I won’t be able to do it justice with words but here’s some great information on how it works and I’d highly recommend a visit to see it for yourself.
In the spirit of fostering collaboration, the science day featured sessions focussed around idea and technology exchange. This included demos of science tools all underpinned by the Eclipse framework: Continue reading “Dawn Developer Workshop, June 2014”
Using Eclipse Common Navigator Framework for the NeXus Navigator
Requirement:
The Eclipse common navigator framework (CNF) is used as the basis for the NeXus Navigator within the DAWN Science platform. The nexus navigator provides a focussed view on nexus files, but in doing so removes the directory and project structure. However, more typically users need to focus on their nexus files within the context of their directory structure (often very deliberately set up and related to the experiment).
 |
| Pre-existing navigator with flat directory structure flat |
So the requirement is to show the existing directory (and project) structure but provide a filter such that only Nexus files are shown.
Solution:
Based on this requirement and the existing codebase, the actual work requires more deprecating code than writing it.
There was a specific content provider class written to flatten the structure. This and the corresponding label provider are no longer required: displaying files in the view is delegated to the default Eclipse resource content and label provider. That way the files always appear the same in any navigator view.
A filter is required, and the common navigator framework provides powerful extension point that allows it be implemented completely statically using xml. The filter automatically shows up in the view customizations but could be hidden if needed.
Rabbit holes:
Based on past experience, using expressions in Eclipse plug-in extension points can be tricky – if they don’t work, it’s not straightforward to debug why. Usually referencing the documentation coupled with a working example is a good starting point. Here’s the filter expression for this case (which came with a certain amount of trial and error):
<filterExpression> <and> <not> <adapt type="org.eclipse.core.resources.IFile"> <test property="org.eclipse.core.resources.extension" value="nxs"> </test> </adapt> </not> <adapt type="org.eclipse.core.resources.IFile"> </adapt> </and> </filterExpression>
In particular, note it is best to use the tag rather than to ensure the filter works not just for files but anything masquerading (or adapting) to the IFile interface.
Testing:
There is no Java code provided that requires unit tests. Using the extension point takes advantage of the pre-existing testing and repeated use by the open source community. The expression can be verified and so tests for the navigator are naturally rolled into tests for upcoming features intended for the navigator.
Resources:
- Common navigator framework – http://wiki.eclipse.org/index.php/Common_Navigator_Framework (the blog resources are particularly useful)
- Eclipse expressions reference – http://wiki.eclipse.org/Command_Core_Expressions
P2 Update Site for the DAWN project – the final piece of the puzzle
The Problem
The DAWN Science project has an update site, but an install of the product does not have the site automatically appearing in the ‘Available Software Sites’. This makes it difficult for users to upgrade their DAWN installation.
 |
| Before: Sites list is empty |
Workaround
Users can manually add in the site, but would need to know where to find the site. So even if users have the site URL, this is still an unnecessary hassle and definitely a significant barrier to upgrade.
Complications
Over the years the Eclipse upgrade mechanism has changed dramatically, culminating in the P2 framework. A simple google search provides lots of out-of-date information mixed in with the key information (hint: anything referring to features and update sites is pretty much deprecated). P2 is a powerful and therefore complex mechanism. Even P2 developers admit things could be better – from the Eclipse help on P2 metadata:
Disclaimer: Authoring p2 metadata is something we expect to support with better tooling in a future release.
Most update site tutorials available do not address this final step, probably because its a product deployment issue, beyond the scope of the tutorials in question.
Solution:
P2 can be a complicated beast, but the key information is out there if you know where to look.
The solution is to create a touchpoint advice file, place it the appropriate location and configure it with the site information.
For DAWN that boils down to creating a new p2.inf file which is colocated with the org.dawnsci.base.product file. The file is configured with the update site information – here’s the key bit of magic.
This is essentially adding in a line with the instructions.configure key and the value in the specified format – see here for details.
 |
| After: Sites list automatically populated with DAWN update site |
Testing:
As ever, testing is the trickier part of the job. Using the existing Squish framework, two tests are added in.
The first test launches DAWN and makes sure an update site is listed. This test ensures the list is not empty, it does not check the content of the list. While a check could be added to check the value of the site, this would make the test unnecessarily fragile and require updating every time the site is updated. However, the content of the list of sites is added to the test logs to provide room for further checks if desired in the future. This is a regression test to ensure the codebase never reverts to the original problem.
The second test actually provides a smoke test for the update site itself. This test launches a previously released version and then runs a full update against the DAWN p2 update site. The test passes if the p2 infrastructure returns success and DAWN restarts successfully. (Note this test is pending as it first requires the actual site locations to be approved).
Resources:
Crowdfunding PyDev
Kichwa Coders is now a silver sponsor for the PyDev project.
We’ve been using PyDev since 2008, and it is truly the best Python development environment out there. With such superb features like its context-sensitive code completion, rich debugging and testing integration it is a tool that has helped us focus on the real programming problems at hand. The development effort, led by Fabio Zadrozny, is highly responsive and always forward-looking.
We are dedicated to supporting such excellence in open-source projects for our and the benefit of the whole developer community.
We look forward to the continued development of PyDev, backed by the Python community. We are also excited by the new features and the LiClipse project.
Join us to support this worthwhile cause at indiegogo.
Read more about PyDev and Fabio’s blog where he explains more about the history and motivation for crowdfunding.
Kichwa Coders 