You are viewing outdated content for BUG. If you have a BUG Y.T. edition or 2.0 series device, please visit our updated wiki: http://wiki.buglabs.net
Hacking the Runtime
From BUG Wiki
Contents |
Introduction
So you have your Bug (Virtual or otherwise), you've written some apps, you spend your free time in #buglabs (irc.freenode.net), and now you're itching for more. So what's left to do? Well, you could hack the runtime. What's the runtime, you ask? The Bug's Java runtime stack is built on top of OSGi, and all the source is available under the GNU GPLv3 from our CVS server. Why would you want to do this? Here's the skinny: the Bug is all about you. It's open so you can change it. If there's something that you need your Bug to do that it doesn't currently, you can make it happen. What's more, it's a good bet that if you want it, a whole bunch of other people want it as well. If you write some code that you think would be useful to others, you can send it our way and we'll get it integrated into the main tree so that everyone can benefit from it.
So that was the What and Why, now here's the How: This guide will show you how to get your build environment set up in Eclipse, how to run your own custom Virtual Bug, how to get the code onto your Physical Bug, and how to contribute your code back to the project.
Just like everything else we do, this guide is open, so if you think of any improvements that could be made, by all means, hit the edit tab at the top of the page and include them. Now with those formalities out of the way let's get on to the good stuff.
Getting Started
Setup
This guide assumes that you have already installed Eclipse and Dragonfly and know how to get around the SDK. If you aren't quite there yet, you might want to check out the Dragonfly SDK Guide first. Start off with a new workspace in Eclipse. Make sure you're in the Java perspective and not the Dragonfly perspective.
The first step is to add the Bug Labs CVS server to Eclipse and check out the TeamSets. From the File menu, choose New->Project, select Projects from CVS, and click Next.
Use the following CVS settings:
- Host: cvs.buglabs.net
- Repository path: /root
- User: anonymous
- Connection type: pserver
- Use default port
Then hit next.
On the next pane, choose Use existing module and scroll down until you see TeamSets. Select TeamSets and click Finish.
Getting the Code
Now that you have the TeamSets, you're good to go get the code. TeamSets are lists of modules that you can have Eclipse check out. Right click on BUG.psf and VirtualBUG.psf and choose Import Project Set. This will have Eclipse check out all the modules you need. You'll probably get a whole lot of errors when you first check out the code. This is a known bug. Hopefully Angel will fix it some day. Don't hold your breath though. If you quit Eclipse and open it again things should be fine. You'll probably also run into this from time to time when you start up Eclipse: there weren't any errors in the code when you quit, but now there are tons. This is the same problem. It can usually be fixed via a combination of running Project->Clean... and making one of the files dirty. Adding and then deleting a space (don't forget to save afterwards) in a manifest file usually helps. Usually running Clean... followed by editing one of the manifests will do the trick, but its really more of an art than a science. If you have trouble with this, just pop into IRC and someone will get you back on track.
Setting Your Build Path
I forgot to write this part. It's important though.
Setting Up Your Custom Virtual BUG
Now that you have the code its time to set up your very own Virtual BUG. From the Run menu choose Open Run Dialog.... From the Run Dialog, select Concierge OSGi Framework from the list on the left and then click on the New launch configuration button (upper left in the toolbar). Give your launch configuration a name. There are two tabs we care about here. Bundles and Concierge. We'll start with Concierge.
Under Concierge Bundles, check OSGi. I'll write more later.
