Archive for July, 2007

Jetlag

Monday, July 30th, 2007

Bah, why do I always sleep OK in Japan – until the third or fourth night when I just can’t sleep at all? And why does that always correspond to the night before an important customer meeting?

Sigh. Special thanks to those who’ve phoned or text messaged me at 5.30AM Japan time every day of this trip so far – Claire, Henrietta, Jelte and anyone else I’ve forgotten. And extra-special thanks to Vodafone for selling me my dire M600i which is now so hopelessly broken that I can’t access the icons on the top half of the screen, thus preventing me from getting into flight mode to avoid such things (given that I want to use the phone as an alarm clock).

Grumble grumble. 

Creating Java code for use inside and outside Eclipse plugins

Monday, July 30th, 2007

Eclipse is very good at creating Eclipse plugins. No surprise there. It’s also very good at creating JAR files for use outside Eclipse. But if I want to write some Java code for use inside Eclipse and outside Eclipse, it’s not obvious what to do. So far I’ve found various different methods, all of which have pros and cons.

Method Pros Cons
Create single PDE project. Use in both a PDE and a JDT context, exporting as a JAR when necessary Works, mostly Slightly odd behaviour relating to the cleanliness of projects – sometimes it doesn’t seem to build the project properly when it’s used from another non-Eclipse project. I don’t know if that’s because I’ve added a PDE nature. Secondly, I need to make sure that I don’t use any Eclipse classes within the code
Create entirely independent Java projects. Use my source-code-management system to keep the source code synchronised, roughly, between the two. I think this is what the Eclipse designers probably expected. It’s always wise to go along with what the software designers expected, or you’ll run up against their invalid assumptions later on. Especially with Eclipse. Each time I change the code for the Java project, I have to go and mess about in Subversion to copy the code across to the plug-in project (or vice versa). Not practical at all.
Create a standalone Java project. Use PDE to “convert to plug-in project”. Irrelevant. Just converts one type into another – doesn’t allow the two to exist together.
Create Java project. Create JAR exporter. Export as JAR. Create “Plug-in project from existing JAR archive”. Resulting plug-in project works well. There is no way to automate the export as a JAR. I can make it a bit easier by saving the JAR’s manifest and its .jardesc file somewhere in subversion. But each time I change the original code, I’d have to right-click on the jardesc and select ‘build JAR’. This method might be viable if there were a way to export the JAR-production process as an Ant buildfile, so that I could build it each time I build the original Java project. Unfortunately, although that seems possible with some of Eclipse’s exporters, the JAR exporter doesn’t seem to be one of them.
Create Java project. Create plug-in project. Delete ‘bin’ folder. Create new linked folder pointing to the ‘bin’ directory of the original project. Doesn’t work. Eclipse gets confused that it doesn’t have to build any source code, and some features of the PDE seem to depend upon the presence of the source code rather than the binaries (such as the nice selection of classes within the plugin.xml and MANIFEST.MF editors).
Create Java project. Create plug-in project. Delete ‘src’ folder. Create new linked folder pointing to the ‘src’ directory of the original project. It works! Eclipse builds two copies of binaries. I don’t fully trust it to observe changes in the original source code and rebuild the binaries properly (I guess it ought to be OK – there’s no real reason why dependency tracking should work less well over linked folders). When debugging, I don’t trust it necessarily to open the source code properly. If it does, I seriously doubt that Subversion will allow me to work with the linked folder. Makes my projects non-mobile, since I have to include absolute file locations in them.

I’m a little suspicious of the first, most obvious, method but that’s what I’m going to stick with for now.

Ade on a Plane

Sunday, July 29th, 2007

I’m writing this from 35,000 feet, somewhere above Archangel, Russia. It’s 5:40 pm, or 1:40 am, depending. I’m off to see some customers-of-customers in Japan for a few days. Along the way, I get to go to Jason‘s barbeque which can’t be bad. But, given there’s no room in Japan to grow cows, I wonder how he’s going to magic up some burgers?

Now

Monday, July 23rd, 2007

Oh, and you may have noticed – I’m blogging again and working on code again. For now. I’m approaching the end of my current contract, and everything’s comfortably ahead of schedule, so I’m only working part-time. I could just finish the contract early, except I’m off to Japan next week to wrap it all up.

CM

Monday, July 23rd, 2007

To those who work outside software, you may be wondering what ‘CM’ is. It stands for Configuration Management, and (largely) refers to the backing up of every single change you make to your software. That would be simple. But it also takes care of the fact that several people may be making changes at once. It backs up each of their changes, and provides some sort of facility to merge them back together again when desired. These parallel lines of development are usually called branches.

What use does Macrobug have for that, I hear you ask? With only one developer…Well, the developer in question (me!) works on several different things at once. I have one branch (‘trunk’) which contains all Macrobug’s most stable code. There are also branches representing experimental major development I’m doing, for example, trying to rip out Eclipse dependencies from the heart of my code. And finally there are branches representing release-quality code. Except I haven’t got any of those yet.

Why am I thinking about CM at the moment? Because when designing these branch structures, it’s easy to make assumptions. Right now my branch structure contains the word ‘Eclipse’ – whoops. If ever I want to remove dependency on Eclipse, I have choices:

  • Create a parallel branch structure for the new code
  • Painstakingly transfer everything from the old structure to the new structure.
  • Have an inaccurate name

At Symbian I was always massively careful to avoid such assumptions because I knew the pain of moving away from them later. I tried here too, but missed this one. I’m not sure what to do yet. Ah well. Not a big deal in the grand scheme of things.

Current contract nearly finishing

Sunday, July 22nd, 2007

I have just two more weeks of this contract. After that, I’m off to Somerset to spend a couple of weeks looking after my Mum after a minor operation. I plan to spend this time working on my annual accounts (at the end of July I’ll have been going for a whole year!) and readjusting my software based on the experience I gained during my last contract at a major phone manufacturer.

After that… it depends. I may actually be in a position to try to sell some software… or otherwise I’ll find another contract. I have at least two tools-related contract leads.

Oh, and I need to spend some time trying to persuade my current contract to pay up. Hmmm.