Archive for the ‘Eclipse’ Category
In my prior post Android: Attaching Sources to Libraries in Eclipse I noted that ADT version r20 added the ability to link sources to libraries in the Android Dependencies classpath container in Eclipse. Although this was a welcome addition, the method used to link sources is a bit cumbersome: you must create a .properties file alongside each library, and add a property that points to the source jar.
I felt this could be a lot simpler if you are willing to adopt a convention for the location of source jars. Once the convention is established, adding linked sources is as simple as placing the source jar in the expected location. This makes the process as seamless as the Android Dependency container is for adding libraries in the first place.
So I’ve made this possible via a new libproperties task in my zutubi-android-ant project. This task inspects the jars in your libs/ directory, looks for corresponding source jars by naming convention, and adds appropriate .properties files when sources are found. If you’re willing to accept the default convention, where source a source jar for library libs/foo.jar is placed at libs/src/foo-source.jar, then this simple Ant target can be used to generate the required .properties files for you:
<target name="link-sources"> <zaa:libproperties/> </target>
Of course you’ll need to import the zutubi-android-ant tasks into your build file first. If you want to ensure sources are present for all libraries, set the attribute failOnMissingSrc to true and your build will fail if any source jar is missing. You can even establish your own conventions, using a regular expression to match the libraries and a replacement string to generate paths to source jars:
<target name="link-sources"> <-- libs/alib-1.3.jar maps to libs/src/alib-src-1.3.jar --> <zaa:libproperties failOnMissingSrc="true" jarPattern="(.+)-([0-9.]+)\.jar" srcReplacement="src/$1-src-$2.jar"/> </target>
Head over to the new zutubi-android-ant home page for more details, including quick-start instructions to get the tasks installed in your build in minutes.
Since ADT r17, Android projects in Eclipse have had a nice property: all jars in your libs directory have been automatically picked up by Eclipse projects under a magic “Android Dependencies” entry in the build path. Ant builds use the same conventions, so adding a library is as simple as dropping it into the right directory. Unfortunately, though, this magic came with a major limitation: there was no way to attach sources to these libraries (see issue 27940). This led me to duplicate build path entries manually just to get source attachments.
Good news: in the just-released r20 version of ADT, Google have provided a solution to this problem. It’s not well advertised, but if you check out comment 21 on the aforementioned issue, you see that by creating a properties file for each library, you can tell ADT where to find the sources. So, for example, if you have a jar named:
you can create a properties file alongside it named:
Within the properties file you can add a src property set to the relative (or absolute, but that’s version-control-unfriendly) path of the source jar, zip or directory. Say, like me, you put it in the libs/src subdirectory, your properties file might look like:
Once you’ve added the properties file, refresh the project in Eclipse and voilà: the sources will be attached! A similar property named doc is supported for javadoc attachments.
Although this new feature is very welcome, I feel like it could use a bit more fine tuning. The main issue is the need to create a separate properties file for each jar. I keep my source jars in predictable locations, with conventional names, so I should be able to configure the convention once and have everything Just Work from then on. Heck, I’m not sure why there isn’t a default convention, which I could just follow with no further configuration!
One of the challenges when starting out with OSGi is finding information on the basics. The official site offers a few articles on specific topics, but no real tutorials. Probably the best resources on that site are the technology overview and the technical whitepaper, but neither document helps you to get your hands dirty. However, there are some other tutorials and presentations about that dig into more detail:
- The OSGi and Gravity Service Binder Tutorial on the Oscar site starts with the simplest bundle and works up. A good starting point, even though the service binder is Oscar-specific (the concept is still useful, however, and explained from first principles).
- The Knopflerfish tutorial, which again starts from the very basics. Some of the content is specific to Knopflerfish, but the OSGi basics are also covered in a hands-on fashion.
- The aQute OSGi Tutorial, which is a detailed presentation with accompanying source code. Uses Eclipse/Equinox as a basis to develop some simple OSGi-based applications. A good next step once you know how to make the simplest bundles.
These links should help you get over the initial hump with OSGi.
As Jason mentioned previously, we are in the process of introducing OSGi into the core of Pulse to handle our plugin support. Since OSGi is also the core of Eclipse, we decided to that a trip to EclipseCon 2007 would be a great way to introduce ourselves into the community and see how people are using OSGi.
It promises to be a very interesting trip, not least for the fact that both Jason and I use IDEA for our development. I have not used Eclipse for quite some time, and last time Jason tried, it killed his mouse. But just maybe it is time to give Eclipse another try? With its support for developing plugins, it will certainly help with developing extensions for Pulse.
If anyone is interested in catching up with us while we are state side, send us an email. We are looking forward to talking to Pulse users and a little madness readers alike.
So what is OSGi? If you head to the official website for the answer, you could be forgiven for thinking you had stumbled on a game of buzzword bingo. The terms “universal middleware”, “service oriented” and “component based” show up in the first couple of sentences! Putting marketing-speak aside, however, OSGi turns out to be a mature standard for dynamic modules (read: plugins) for Java. Despite the buzzwords, it is also pleasantly simple at its core (plugins are just Jar files with metadata in the manifest). If you’re looking to create a plugin-based application, or to add a plugin system to your existing application, then you should look into OSGi.
In our case, we are adding a plugin system to the next major version of Pulse. We have decided to go with OSGi for a variety of reasons:
- A robust standard for the basic requirements of a plugin system: such as plugin metadata, dependencies, classloading, service management, dynamic loading/unloading and so on. Why reinvent a less complete system?
- A simple core: OSGi plugins (known as bundles) are just plain old Jar files with some metadata. This simplicity will make our life much easier.
- Existing open source implementations: we have chosen the Eclipse foundation’s Equinox implementation, but there are others such as Felix, Knopflerfish and Oscar.
- Eclipse tooling support: as Eclipse uses OSGi under the covers, the Eclipse Plugin Development Environment has tool support for creating and managing OSGi bundles. One of our goals is to make the lives of plugin authors as simple as possible: tool support helps achieve this.
Of course, it is not all good all of the time. There are some challenges we face along the way:
- Lack of documentation: it is seriously difficult to find good documentation about OSGi and the implementations, apart from the standard itself (which happily is reasonably readable). The saving grace is having the Equinox code and a helpful development community.
- Embedding Equinox: the Equinox framework, as part of the Eclipse project, has a certain bias towards being used as part of the larger Eclipse platform (and Rich Client Platform). This is changing over time, but we are finding some interesting challenges embedding Equinox in Pulse.
- Impedence mismatches between Pulse and OSGi: at times the default OSGi behaviour is at odds with how we would like plugins to act in Pulse. For example, OSGi mandates that the state of plugins is persisted by the framework, whereas we want Pulse itself to have control over their state.
As we continue the implementation of a plugin system for Pulse, I’ll post more about the particular things we learn along the way. Hopefully this information will help fill the documentation black hole, particularly in a new area for Equinox: embedding in a standalone application.
You are currently browsing the archives for the Eclipse category.