Pisang Quiet

OSGi in Action in print

2011-04-06T00:55:00.002+08:00

Just heard from Manning (publishers of OSGi in Action) that our book will be in print tomorrow!! This is great news - thanks again to my co-authors Richard, Karl, and David; as well as all the managers, editors, and graphics people at Manning who put up with us for so long!

Free chapter samples are available from http://manning.com/hall/, but there's nothing quite like having a physical copy lying around on your coffee table ;)

OSGi vs Jigsaw, JSR 330 vs 299, OBR vs P2, Maven vs ...?

2009-06-28T15:33:00.014+08:00

While I enjoy a good technical discussion I try to avoid conflict where I can. So it's somewhat worrying to wake up and realize that all the projects I work on are involved in heated debates!

The most obvious one is between OSGi and Jigsaw - now personally I have no issue with a modularity system that's optimized for the JVM. Having done time as a JVM developer I realize that often what's best for the JVM is not what's best for applications, and vice versa. Sometimes you just need shortcuts that you can trust to 'internal' users but would be dangerous if exposed to everyone, for example the Unsafe class. That said, I would be cautious in using Jigsaw for modularity outside of the JVM - this is not based on any technical point at the moment, it's purely inertia on my side while Jigsaw is being fleshed out. I don't have much spare time and I'm currently in my comfort zone with OSGi.

My hope is that JSR 294 can act as a bridge between OSGi and Jigsaw by standardizing some of the details needed to declare and define modules - like naming, version ranges, imports, exports, etc. We could then use JSR 294 metadata to configure OSGi bundles in place of the dependable (but non-type-safe) manifest, removing a major bugbear of new developers. Unfortunately it looks like JSR 294 might fudge this issue and go with opaque strings that only the target module system understands :(

In my ideal world JSR 294 would define a small common module API without trying to standardize a complete module system. Trying to capture too much detail can lead to long, contentious discussions and puts a straightjacket on future solutions. Specifying not enough (opaqueness) makes portability a joke.

Does this sound familiar? This is essentially what's happening with JSRs 299 (Contexts and Dependency Injection) and 330 (Dependency Injection for Java). JSR 299 defines the API and semantics for a complete dependency injection system for Java EE, whereas 330 is defining a much smaller API that just covers injection points and configuration in Java SE. Ideally people could code to the smaller 330 API to gain some portability between DI frameworks without having to rewrite or use a completely different API for the more complete JSR 299 specification. Developers can choose the level of portability they want.

While there has been some recent friction on the JSR 330 list, it does look like people are making significant concessions to standardize this reduced API. This is great news for people like me who provide DI extensions (in my case peaberry) because by adopting this API my extension could conceivably be used with Guice, Spring, or any other framework that supports JSR 330 - even fully-fledged JSR 299 systems.

Now if the same thing happened with JSR 294 I could package peaberry so it could be used as an OSGi bundle, or a Jigsaw module, or even as an element in some future modularity framework I've not yet heard of.

Unfortunately finding the sweet spot between defining too much and too little is a hard process, and isn't helped by personality clashes. Another example of this is the recent flare up between P2 and OBR... both provide a form of requirement/capability model to help decide what bundles should be deployed to satisfy a given need, but P2 goes further and defines additional details necessary for Eclipse installations. That doesn't mean they can't co-exist or there isn't a common subset of metadata they could share, which is what RFP 122 is hoping to achieve.

Indeed the Nexus Maven repository manager (Professional Version) already supports P2 and will support OBR in 1.3.5 - and when the updated OBR spec is finalized I'm sure it will be just as straightforward to handle that as well.

The last project from my title is Maven - a name associated with peace, harmony, and logical discussions that has never been involved in this kind of dispute ;) Seriously though, it is interesting that the next version of Maven may be based on both Guice (hopefully using the JSR 330 API) and OSGi (abstracted via the JSR 330 API using peaberry). Its artifact resolver will probably be pluggable, allowing it to take advantage of both P2 and OBR metadata.

So in the end these spec discussions are not the end of the world: even without agreement it is often possible to map between different forms of API and metadata. Of course it is much easier if things like version formats are standardized (any chance of this 294 gurus?) but even with opaque strings I bet someone will end up writing a Jigsaw-OSGi adapter...

Distributed OSGi with Newton + peaberry

2009-05-05T01:51:00.005+08:00

Last week I finally got around to testing peaberry with the Newton distributed OSGi framework from Paremus. It was surprisingly easy to use peaberry with Newton, I only had to make a couple of changes to support native LDAP filter strings when querying the OSGi service registry:

http://code.google.com/p/peaberry/issues/detail?id=34

These changes are now available in the 1.1.1 release of peaberry. I've also written up a distributed OSGi example based on the existing Spring example.

The new example unpacks on top of a binary installation of Newton 1.3.2 and shows how you can use property files to switch between local and remote services without changing your compiled Guice bindings.

While writing the example I realized that there are a lot of cool abstractions we can build on top of the basic peaberry API. I'm trying to follow the model used in both Guice and OSGi and keep the core API as simple, lean, and mean as possible while providing ways for others to build even more user-friendly layers, such as BindForge, on top.

There are two essential layers I would like to add in the next peaberry release:

Configuration - but not tied directly to the OSGi CM service

Lifecycle - but again, not tied directly to Bundles and Activators

which will hopefully make it really easy to configure and tie services together.

I'm also considering adding extender bundles to scan for service annotations or scrape 'blueprint' XML and dynamically configure the relevant bindings at runtime, but that would be more of a 1.3 feature. If you're interested in building on top of peaberry, or you have an interesting idea for a new feature, please let me know.

Until then take a look at Newton+peaberry and see distributed OSGi in action!

peaberry - EclipseCon slides now available

2009-03-28T01:25:00.005+08:00

My EclipseCon talk on peaberry seems to have been well received, although I think it would have been even better if I'd reduced the technical content to allow time for more questions. I always find short talks harder to plan than long talks, and this was a good learning experience.

If you missed the talk you can either view it on gPublication or download the original presentation.

Of course hearing from my boss that he was closing our company the night before didn't really help. But I'm glad I got the chance to visit EclipseCon one more time and expand my network, which will come in useful for my upcoming job search.

So if you know of any companies interested in hiring someone with good Java, OSGi, and Maven skills... let me know :)

maven-bundle-plugin 2.0.0 released!

2009-03-05T09:43:00.005+08:00

The Apache Felix team is pleased to announce the release of maven-bundle-plugin 2.0.0

This release uses the latest bndlib (0.0.311) which requires you to build with a Java5 JDK. You can continue to target earlier JVMs while building with a Java5 or later JDK by setting the source and target levels in the maven-compiler-plugin configuration.

Here is the list of issues fixed in this release:

Bug

[FELIX-545] - Export-Package version inconsistencies.
[FELIX-546] - Import-Package version inconsistencies.
[FELIX-549] - Import-Package should not include "snapshot" from snapshot dependencies
[FELIX-660] - "Class in different directory than declared" error when bundle classes in a directory other than bundle root
[FELIX-677] - Parser throws error when DynamicImport-Package contains attributes
[FELIX-699] - manifest goal does not interprete _include instruction correctly
[FELIX-782] - Manifest goal ignores version attribute specified in _exportcontents
[FELIX-807] - conversion of JAR into bundle fails if there are classes is the default name space
[FELIX-831] - bndlib unnecessary modifies valid OSGi Bundle-Version numbers (update to bndlib 0.0.293)
[FELIX-843] - Regression: BND 0.0.295 does not augment Ignore-Package with excluded import packages
[FELIX-850] - Wrong symbolic name computed when groupId is a single segment string.
[FELIX-864] - A wrong symbolic name is calculated if artifactId starts with lastGroupIdSegment-.
[FELIX-899] - Version attribute missing from Import-Package on provided dependencies
[FELIX-907] - Regression in latest BND code: negated exports are applied to private packages

Improvement

[FELIX-684] - Enable excludeDependencies to check groupId, version, etc. rather than only artifactId
[FELIX-806] - changing the internal configuration of the archive plugin doesn't seem to be possible
[FELIX-941] - Support singleton & fragment-attachment directive generation

New Feature

[FELIX-912] - Improve default Export-Package / Private-Package settings by scanning the project source

A quick bundle example using the classic Maven quickstart project:

  mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app

# edit the pom.xml, change packaging from jar to bundle and add:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>2.0.0</version>
        <extensions>true</extensions>
      </plugin>
    </plugins>
  </build>

  mvn clean install # you should now have a valid OSGi bundle

plugin docs: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
plugin FAQ: http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html
bnd docs: http://www.aqute.biz/Code/Bnd

--
Regards, the Apache Felix team

maven-bundle-plugin 2.0.0 coming soon

2009-02-27T19:36:00.003+08:00

Just started a vote for the next major release of the maven-bundle-plugin, if all goes well it will be published to Maven central next Wednesday (4th March).

Guice feature comparison

2009-02-22T12:27:00.005+08:00

Yesterday Jesse added this table to the Optional AOP page of the Guice wiki:

	Guice 1.0	Guice 2.0	Guice+AOP 2.0	GIN
Library size	544Kb	420Kb	640Kb	0Kb (code gen)
High performance	✔	✔	✔	✔
Binding EDSL	✔	✔	✔	✔
Scopes	✔	✔	✔	✔
Typesafe	✔	✔	✔	✔
Fast reflection	✔ (cglib)		✔ (cglib)	✔ (code gen)
Line numbers in error messages	✔		✔
Method interceptors	✔		✔
Provider Methods		✔	✔	✔
Binding overrides		✔	✔
Tool-friendly SPI		✔	✔
Child Injectors		✔	✔
Servlet Support	Scopes Only	✔	✔
Error Reporting	Good	Better	Best	Best

I think it's a great summary and shows how flexible the new release will be.

Guice-Peaberry vs Spring-DM

2009-01-13T01:42:00.003+08:00

six times as fast, half the size!

Of course it's never that simple, these are just some fun measurements I took today using a trivial testcase that injects an OSGi service. They completely ignore functionality, flexibility, usability, and many other *bilities... flame-on!

Happy new year!

2009-01-07T02:23:00.003+08:00

Just completed one of my new year resolutions and uploaded a release candidate of peaberry. See my message on the Guice-OSGi group for a few more details.

OK onto my next resolution, back to writing more chapters for OSGi in Action...

Want to hear the latest on Guice and OSGi?

2008-12-18T18:53:00.009+08:00

Then you'll want to attend EclipseCon 2009, where you can hear me talk about using Guice and the peaberry extension to blend OSGi services with Eclipse extensions:

http://www.eclipsecon.org/2009/sessions?id=315

I'll also be running through some of the design decisions behind peaberry which I think are pretty neat - like the recent work on "outjection" that lets you share services between registries and watch for service updates. If I have time I'll also discuss some thoughts about lifecycle support (for some background see Todor's recent request).

I'm going to be around for the whole conference, so you'll have plenty of opportunities to ask me questions about peaberry, Pax-Construct, the maven-bundle-plugin, or the "OSGi in Action" book :)

How much OSGi should I use?

2008-12-09T16:20:00.005+08:00

This began as a quick reply to a question on the Felix users list about bundling third-party libraries, but these days once I start writing I find it hard to stop! Hope you find it useful...

It's actually up to you - OSGi doesn't force you to make everything a bundle, it merely helps you when you decide to modularize.

So if you want to put third-party libraries on your application classpath and use the "org.osgi.framework.bootdelegation" property to make them visible to all bundles then you can. You could then concentrate on modularizing your application without worrying about legacy classloading issues - however it would also mean you couldn't replace these libraries at runtime, or have multiple versions of them loaded at the same time. Additionally, if you use tools to generate OSGi manifests you'd need to tell them that these packages should not be marked as imported, as they're available instead using bootdelegation - otherwise your bundles would have trouble resolving, because no other bundle would be exporting these packages.

Or you could keep the libraries on your application classpath and use "org.osgi.framework.system.packages.extra" to augment the exports from the main system bundle. Unlike bootdelegation, your bundles would need to import any of these packages they want to use - and these imports would then get wired to the system bundle. However, because you're now using OSGi resolution to find these packages you could replace them at runtime and have other bundles provide alternative versions. The downside is that you may find issues with a few legacy libraries that expect the "classic" model (ie. everything on the application classpath)

Later on you might decide to move libraries from the application classpath into one or more OSGi bundles - you could either crack open the library and add OSGi metadata to the manifest to export everything, or use a tool like BND to create a new jar based on the original. This is great if you want to share libraries between bundles - but if the library is only used by one bundle then it might make more sense to embed the library inside that bundle, especially if it's an implementation detail and you never expect to export any packages. Again you have a choice: you can unpack the library inside your bundle, or embed the jar as-is and add it to your Bundle-ClassPath (OSGi supports "jars within jars").

Once you have the third-party library as (or inside) an OSGi bundle then you can start thinking about making certain packages private, and add a Bundle-Activator to initialize and clean up resources and/or threads. Using an activator is optional and while it will introduce a compile time dependency to OSGi, it doesn't force the library to use OSGi at runtime. You can still use the library in classic Java applications, because they won't attempt to load the activator class. This is cool, because it means you can fully participate in the OSGi lifecycle without affecting anyone not interested in OSGi.

The best part is that you can mix any of these approaches in your application and you can decide when move between them. You're not forced to make everything a bundle, and you may even decide to move bundles back to the application classpath. Feel free to use as much or as little of OSGi as you like :)

Cat massage, courtesy of Friesia

2008-12-04T18:20:00.003+08:00

OSGi (Services) in Action

2008-11-26T02:31:00.003+08:00

Just noticed that my chapter on OSGi services has reached the Manning Early Access Program. Hope you enjoy reading it, and remember to post any comments or questions on our author forum.

Here's some of the topics covered in Studying Services:

The what, why and when of services

OSGi services in action!

Dealing with dynamics

Using services in the paint example

How services relate to modularity and lifecycle

Framework services

Do you remember to unget OSGi services?

2008-11-17T02:20:00.004+08:00

Just posted the first set of code examples for OSGi in Action, chapters 1 to 4:

http://code.google.com/p/osgi-in-action/

The answer to when you should "unget" an OSGi service (and why you should bother) will be explained in chapter 4 of the book, which will hopefully reach Manning's Early Access Program very soon.

Spoiler alert: take a peek at chapter04/dynamics.

OSGi in Action!

2008-10-24T00:32:00.004+08:00

The kind folks at Manning have just made the first chapter of "OSGi in Action" available through their early access program: http://manning.com/hall/

Unfortunately the figures seem to be chopped off in the PDF, so apologies for that in advance... we're using OpenOffice to write the book and this is apparently new for Manning, so there's still a couple of bugs to squash in the publishing process. Never mind, the next update will be much better!

Richard, Karl and I are eagerly working on getting the next few chapters ready for MEAP. This is where we delve into the different layers of OSGi (modularity, lifecycle and services) with plenty of examples to explain the differences and best practices.

Those of you signed up to MEAP can send comments and corrections via the author forum. You can also reach us via the usual lists (Felix, OPS4J, etc.)

That's all for now - got to get back to writing!

Karangan - Kampung halaman saya

2008-10-14T15:30:00.003+08:00

Nama kampung saya Guarlford. Guarlford terletak dua batu dari sebuah kaki bukit besar yang bernama Malvern Hills. Di sekeliling Guarlford ada banyak ladang, lembu tenusu dan anak biri-biri.

Pada musim bunga pemandangan sangat cantik sebab semua tumbuh-tumbuhan hijau dan segar. Pemandangan musim gugur juga sangat cantik sebab daun-daun pohon menjadi warna-warni.

Walaupun jumlah penduduk di sekitar Malvern adalah tiga puluh ribu orang, jumlah penduduk Guarlford hanya dua ratus lima puluh orang sahaja.

Kampung saya sangat tua, ia wujud sejak tahun 1275. Ibubapa saya dan rakan-rakan mereka telah menulis dua buah buku tentang sejarah Guarlford yang anda dapat beli dari Amazon.

OSGi Text Scrambling Service

2008-07-30T04:15:00.005+08:00

Here's most of the code from the peaberry example I mentioned in my previous post - as you can see, peaberry lets you import and export OSGi services from your Guice enabled application, without introducing a dependency on the OSGi API. In fact you can even plug your own service frameworks into peaberry.

EXPORTING BUNDLE

package examples.scrambler.impl;

import static org.ops4j.peaberry.Peaberry.registration;
import static org.ops4j.peaberry.util.TypeLiterals.export;

import com.google.inject.AbstractModule;
import com.google.inject.Key;

import examples.scrambler.Scramble;

// here's where we bind the exported service...
public class ExportModule extends AbstractModule {

  @Override
  protected void configure() {
    // note: the service is exported at injection time
    bind(export(Scramble.class)).toProvider(
        registration(Key.get(ScrambleImpl.class)).export());
  }
}

package examples.scrambler.impl;

import static com.google.inject.Guice.createInjector;
import static org.ops4j.peaberry.Peaberry.osgiModule;

import org.ops4j.peaberry.Export;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

import com.google.inject.Inject;

import examples.scrambler.Scramble;

@SuppressWarnings("unused")
public class Activator implements BundleActivator {

  @Inject
  final Export<Scramble> handle = null;

  public void start(final BundleContext ctx) throws Exception {

    // apply the exported service binding
    createInjector(osgiModule(ctx), new ExportModule()).injectMembers(this);
  }

  public void stop(final BundleContext ctx) throws Exception {

    if (null != handle) {
      handle.remove();
    }
  }
}

IMPORTING BUNDLE

package examples.scrambler.test;

import static org.ops4j.peaberry.Peaberry.service;

import com.google.inject.AbstractModule;

import examples.scrambler.Scramble;

// here's where we bind the imported service...
public class ImportModule extends AbstractModule {

  @Override
  protected void configure() {
    bind(Scramble.class).toProvider(service(Scramble.class).single());
  }
}

package examples.scrambler.test;

import static com.google.inject.Guice.createInjector;
import static org.ops4j.peaberry.Peaberry.osgiModule;

import org.ops4j.peaberry.ServiceUnavailableException;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

import com.google.inject.Inject;

import examples.scrambler.Scramble;

@SuppressWarnings("unused")
public class Activator implements BundleActivator {

  // plain text to be scrambled...
  final static String TEXT = "This is a simple test of peaberry.";

  @Inject
  final Scramble service = null; // Guice can actually inject final fields!

  Thread tester;

  public void start(final BundleContext ctx) throws Exception {

    // apply the imported service binding
    createInjector(osgiModule(ctx), new ImportModule()).injectMembers(this);

    // quick'n'dirty test thread
    tester = new Thread(new Runnable() {
      public void run() {
        // support cooperative cancellation
        while (Thread.currentThread() == tester) {
          try {
            System.out.println('[' + service.process(TEXT) + ']');
          } catch (final ServiceUnavailableException e) {
            System.err.println("No scrambler service!");
          }
          try {
            Thread.sleep(2000);
          } catch (final InterruptedException e) {
            // wake-up
          }
        }
      }
    });

    tester.start();
  }

  public void stop(final BundleContext ctx) throws Exception {

    // cooperatively stop the thread
    final Thread zombie = tester;
    tester = null;
    zombie.join();
  }
}

peaberry 1.0 alpha

2008-07-30T04:10:00.003+08:00

You may have noticed I recently uploaded an alpha build of peaberry 1.0

http://peaberry.googlecode.com/files/peaberry-1.0-alpha.zip

today I've also been working on updating the design and user guide pages:

http://code.google.com/p/peaberry/wiki/UserGuide
http://code.google.com/p/peaberry/wiki/DetailedDesign

including a small Eclipse/PDE example I put together in a matter of minutes.
(and which hopefully also works ok on other people's installations of Eclipse!)

http://peaberry.googlecode.com/files/PeaberryExample.zip

At this point I'm feeling good about the API and (unless I hear otherwise) will
concentrate on more "behind-the-scenes" work, and perhaps add a few more
utilities to help developers.

So... if you find any bugs please let me know via the issues tab :)

IdentityHashMap is broken in IBM JDK 5!

2008-07-29T15:31:00.003+08:00

So there I was, happily running some tests with the latest copy of Guice when blam - I got a NullPointerException from inside the injector. Hmmm, I thought, perhaps the latest trunk code is unstable. So I pulled down a stable snapshot... and got the same exception.

Looked at location of the NPE and got even more confused:

CreationTimeMemberInjector.java:87

where it iterates over the cached entry set of an identity hash-map. Added some debug code, and yes - the entry set is valid to begin with, but after stashing it in a list, the list elements are all null. Weird!

Why hadn't I seen this before, I've run the same test many times - then it struck me, today I happened to have JAVA_HOME set to the IBM JDK, while previously I've used the default Sun JDK.

Time to crack open the src.jar from the IBM JDK - lo and behold in IdentityHashMap.java:1142


      public  T[] toArray(T[] a) {
          return (T[])toArray(); // !!!!
      }

that is plain wrong - the specification for toArray(T[] a) clearly states that the provided array must be used if it's large enough:

Returns an array containing all of the elements in this collection; the runtime type of the returned array is that of the specified array. If the collection fits in the specified array, it is returned therein. Otherwise, a new array is allocated with the runtime type of the specified array and the size of this collection.

this behaviour is relied on in other classes from java.util, where they create a large enough array and use c.toArray(elements); to initialize the array contents. Hence the null array when creating a list based on the entry set.

I was going to report this on the "IBM Java Runtimes and SDKs" forum as the problem still exists in the latest service release, but it appears to be offline today! For those interested, here is a simple testcase to recreate the bug:


import java.util.*;

public class IdentityHashMapTest {
  @SuppressWarnings("unchecked")
  public static void main(String[] args) {
    Map map1 = new HashMap();
    Map map2 = new IdentityHashMap();
    map1.put("Hello", "World");
    map2.put("Hello", "World");
    System.out.println("MAP  1 : " + map1.entrySet());
    System.out.println("MAP  2 : " + map2.entrySet());
    System.out.println("LIST 1 : " + new ArrayList(map1.entrySet()));
    System.out.println("LIST 2 : " + new ArrayList(map2.entrySet()));
  }
}

BTW, that comment // !!!! is actually in the original source code, which suggests someone out there knows this is wrong but couldn't be bothered to fix it...

Guice 2.0 and OSGi

2008-06-27T17:41:00.002+08:00

Some cool news: the Guice trunk (which will eventually become 2.0) now includes my patches to support OSGi-style classloading, and also adds OSGi metadata to its jars.

This means that you will be able to take the Guice 2.0 jar and drop it onto any OSGi framework, without having to worry about classloading issues wrt. the internal proxy code. The new code also allows generated proxy classes to be unloaded when they're no longer needed.

So when Guice 2.0 hits the internet, the peaberry project will become a neat little extension library that you can drop alongside the Guice jar to inject OSGi services.

Good stuff! ( no more patches :)

Bio-reboot

2008-05-16T10:51:00.006+08:00

You may (or may not) have noticed that I haven't been as active as usual on various projects. I've been having stomach issues for the last few months, and after numerous tests the doc decided to "reboot" my stomach by clearing out all the bacteria with antibiotics. He's now started me on probiotics to replace the good bacteria/enzymes (like the ones that help digest milk) that got zapped.

It's going to take a while before things are fully back to normal, and I need to regain about 5kg, but I'm feeling more positive (which is a good sign). The doc did tell me to keep my stress levels down, but that may be difficult when there's so many cool ideas that need implementing ;)

peaberry 0.3 available for testing / review

2008-04-07T23:42:00.002+08:00

I've uploaded a new peaberry bundle along with early design docs:

http://peaberry.googlecode.com/files/peaberry-0.3.jar
(this also contains the source code under OSGI-OPT)

http://code.google.com/p/peaberry/wiki/DetailedDesign

the new design is much less invasive: you can decide to explicitly
add bindings to services without using the @Service annotation if
you want, and you can even use peaberry to inject services from
other registry based systems (by implementing ServiceRegistry).

There's also a small demo to show it working in practice

http://peaberry.googlecode.com/files/peaberry-0.3-logdemo.zip

although this demo doesn't actually do anything useful ;)

I'll upload the user guide tomorrow and then start working on a
production quality implementation of the OSGiServiceRegistry
(the current one is basic proof-of-concept and non-optimal).

Other TODOs:

mandatory services (ie. bundle won't start without them)

service registration (need to find an intuitive approach)

Anyway, please take a look and let me know what you think.

A jolt of Guice

2008-03-07T15:16:00.003+08:00

Fantastic news from this year's Jolt Awards: Guice won the award for "Libraries/Frameworks" beating several other worthy finalists, including the Spring Framework! Hopefully this news will provoke a fresh injection of interest in Guice :)

Certainly I'm feeling more of a buzz about the next release, and can't wait to find time to continue my work on extending Guice to support dynamic injection of services from registries, such as the one in OSGi (http://code.google.com/p/peaberry).

So congratulations to Bob, Kevin and everyone else involved with Guice!

Pax Construct 1.0 released

2008-03-07T15:06:00.003+08:00

I've released version 1.0 of Pax Construct, just in time for EclipseCon! (phew) And now you can find the scripts and plugin on the central Maven repository, so it's even easier to use:

http://repo1.maven.org/maven2/org/ops4j/pax/construct/scripts/1.0/scripts-1.0.zip

Improvement

[PAXCONSTRUCT-66]
- Add all Maven compilation dependencies to the Eclipse classpath

[PAXCONSTRUCT-67]
- Add pax:provision option to select Pax-Runner profiles (-Ddeploy=...)

[PAXCONSTRUCT-68]
- Support use of Pax-Runner argument files (-Dargs=)

[PAXCONSTRUCT-69]
- Support pax:run as alias for pax:provision

[PAXCONSTRUCT-70]
- Provide a pax-provision script that works outside of a Maven project

[PAXCONSTRUCT-71]
- Support provisioning of bundles not marked as provided dependencies

New Feature

[PAXCONSTRUCT-72]
- Add new command "pax-create-module" to simplify creation of subdirectories

Task

[PAXCONSTRUCT-59]
- Look into using velocity instead of groovy to generate the various scripts

Plus several changes to the underlying internals to improve performance and usability.

maven-bundle-plugin 1.2.0 released

2008-01-22T12:28:00.000+08:00

It's finally here, a new stable release of the bundleplugin:


      <plugin>
        <groupid>org.apache.felix</groupid>
        <artifactid>maven-bundle-plugin</artifactid>
        <version>1.2.0</version>
      </plugin>

hopefully the next development cycle won't take so long :)

Using OSGi? Need logging?

2007-12-19T19:54:00.000+08:00

We're very close to the first major release of Pax-Logging - if you're using OSGi and are still looking for a good logging provider, why not try the release candidate:

pax-logging-api-1.0-RC2.jar

pax-logging-service-1.0-RC2.jar

several major open-source projects are already using it to simplify their logging story.

An introduction to Pax tools for OSGi

2007-12-18T23:52:00.000+08:00

I received an early Christmas present this year: my proposed tutorial for EclipseCon 2008 was accepted! Come along if you want to hear how Pax-Runner, Pax-Construct, Pax-Logging, and the rest of the Pax family can make life with OSGi much more bearable :)

Both Alin and I will be there to go through the tools, run demos, suggest OSGi best-practises, and answer questions. BTW, if you have any specific topics you'd like covered, let me know and I'll see if I can work them into the tutorial.

Hope to see you at EclipseCon 2008.

Pax Construct 0.6.2 Released

2007-12-04T16:46:00.000+08:00

Moving to 0.6.2

You can update existing scripts and projects with the pax-update command. Or you can download the new scripts and manually change the maven-pax-plugin version in your project's pom.xml.

Change Log

Bug

[PAXCONSTRUCT-52] - pax-clone has issues with java files containing #. and #stop
[PAXCONSTRUCT-53] - pax-clone corrupts binaries
[PAXCONSTRUCT-54] - pax-validate.bat fails when invoked from cygwin
[PAXCONSTRUCT-55] - pax-import-bundle throws NPE when run outside of a maven project - it should report an error instead
[PAXCONSTRUCT-56] - pax:eclipse error using latest 0.6.2-SNAPSHOT
[PAXCONSTRUCT-57] - Support using Pax-Construct scripts in a directory with spaces under Cygwin

Improvement

[PAXCONSTRUCT-50] - maven-pax-plugin can cause long compilation times when unpacking bundles with embedded dependencies
[PAXCONSTRUCT-58] - Add provided dependencies as required libraries in the Eclipse classpath to better support testing

Task

[PAXCONSTRUCT-51] - Separate archetypes from the main pax plugin and scripts so they can be released separately

oatmeal

2007-11-29T11:56:00.000+08:00

Just thought I'd share a picture of our new cat Oatmeal (or Oatey for short) who we got several weeks ago from a rescue organization. He's settled in very quickly and enjoys distracting me when I use my macbook at home - I'm beginning to suspect my wife is encouraging this behaviour ;)

this is Oatey in "cute" mode (warning: he also has a "biting+scratching" mode!)

EclipseCon 2008

2007-11-28T16:19:00.000+08:00

Well, the submissions are in and it looks like there are some really great talks and tutorials out there - it's a shame there's only so much time available. There was a flood of OSGi related submissions just before the deadline, so Peter can rest easy ;)

If you want to see what's available, take a gander at:

https://eclipsecon.greenmeetingsystems.com/submissions

the submissions process is open and transparent, so feel free to review them and comment on those you'd like to see, or ask for more details on any talks/tutorials.

Hope to see you at EclipseCon next year!

mmm... durian

2007-11-28T14:50:00.000+08:00

One of the benefits of living in Malaysia is the wide range of food available*. It took me a while to get used to eating durian fruit, as the smell reminded me too much of ripe cheese - but now my wife and I can happily eat several in a single sitting.

I don't know exactly when it happened, but one day I was drawn to the smell rather than it putting me off - since then I look forward to durian season and enjoy savouring the different flavours and textures you can find here and in Indonesia. Every fruit is different - and now and again you find a really great durian that you just wish you could eat again :)

These days you can find durian in ice-cream, candy, mooncakes - even doughnuts!

perhaps this could even make Homer Simpson try durian?

(* I also like Indonesian salak but it's hard to find good supplies of this locally)

Pax Construct 0.6.1 Released

2007-11-21T14:49:00.000+08:00

http://repository.ops4j.org/maven2/org/ops4j/pax/construct/scripts/0.6.1/scripts-0.6.1.zip

if you have 0.6.0 installed, you can use pax-update to upgrade your existing scripts (must be run from inside the scripts bin directory).

Release Notes - Pax Construct - Version 0.6.1

Bug

PAXCONSTRUCT-47 - Default classpath entry for an imported bundle is missing when source is unavailable

Improvement

PAXCONSTRUCT-46 - Use latest release of Pax-Runner by default, instead of always defaulting to a known static version
PAXCONSTRUCT-49 - resources out of basic resource path included in details.bnd not copied when cloning, or fix for bundle build

New Feature

PAXCONSTRUCT-48 - Allow users to specify a different bundle groupId, rather than limiting them to the generated groupId

JayView Issue 14: OSGi - not just a four letter word

2007-11-09T10:22:00.000+08:00

The latest issue of the Jayway magazine, JayView, is now out:

JayView issue 14

it includes an article I wrote recently about OSGi - let me know what you think... (FYI, the cover shows the Petronas Towers, which are visible from the office where I work in Kuala Lumpur)

Peaberry: injecting OSGi services using Guice

2007-11-07T23:44:00.000+08:00

Several months ago I blogged about Guice-OSGi, my OPS4J research project looking at using Guice to do dependency injection of OSGi services. Since then I've been distracted with other projects, moving house and our new cat (who almost managed to rewrite my DevCon submission when he took an keen interest in my MacBook, and then managed to disconnect the ADSL line - what a critic!)

Anyway, it seems that to officially use OSGi in a project name it must be an adjective, which is why Spring-OSGi has transformed into: "Spring Dynamic Modules for OSGi(tm) Service Platforms". Rather than try to compete with an equally long title, I decided to resurrect a name I'd previously used for a demo project: "peaberry", which is a special type of coffee bean. (as my wife will tell you, I really like coffee...)

So peaberry is the new Guice-OSGi, and is now hosted over at Google Code:

http://code.google.com/p/peaberry

I decided to host the project there rather than at OPS4J because it makes it easier for people who know the Guice site to find their way to peaberry. BTW, if you're interested in helping out, let me know and I'll add you to the project team.

I've just made the first download available:

peaberry-0.1.jar

which is an OSGi bundle of the latest trunk version of Guice with patches for issue 49 (binding factories) and issue 94 (classloader interception of generated classes) which are needed to use Guice in a reloadable container, such as OSGi. Hopefully these patches will eventually be folded back into the main Guice tree.

The next step is to install a 'bridge' classloader (based on issue 94) to allow generated classes to see both the internal Guice code and external user classes without needing DynamicImport-Package:* in the peaberry bundle. After that I plan to migrate the Guice-OSGi annotation work over to peaberry (based on issue 49) and remove the need to extend a specific base class to bootstrap the service injection process.

As mentioned in my last post, I've submitted a talk about my work on peaberry to the DevCon site, so if enough people are interested I may get the chance to explain all the cool features in person.

OSGi DevCon/EclipseCon 2008

2007-11-06T23:41:00.000+08:00

Only a couple more weeks left to submit talks or tutorials for the next OSGi DevCon. I've submitted one tutorial and a talk so far:

An introduction to Pax tools for OSGi

OSGi service injection using Guice

Have you got an interesting story or project involving OSGi? If so then submit it soon - I don't want to be the only speaker :)

Migrate existing OSGi projects to the latest Pax-Construct

2007-10-19T03:07:00.000+08:00

I'm currently tinkering with a Maven mojo to help people migrate old Pax-Construct (0.1.x) and other OSGi projects to the new Pax-Construct layout. At the moment this mojo only captures the project layout and types of bundles (wrapper, compiled, imported, etc.) but will eventually include the actual bundle source, BND instructions, and other POM customization - like extra repositories.

To try out the new mojo, either download the latest 0.2.1-SNAPSHOT scripts and use the pax-validate command to pull down the latest maven-pax-plugin, or build from the latest sources.

Then go to your OSGi project and call:

mvn org.ops4j:maven-pax-plugin:0.2.1-SNAPSHOT:clone

which should generate both UNIX and Windows build scripts under the target folder.

Make sure the 0.2.1-SNAPSHOT Pax-Construct scripts are on your path, and cd to a temporary directory - you should then be able to call the generated build script, which will recreate the project structure using the latest Pax-Construct commands.

For example:


cd ~/Code/ops4j/pax/radman ; mvn org.ops4j:maven-pax-plugin:0.2.1-SNAPSHOT:clone

cd /tmp ; ~/Code/ops4j/pax/radman/target/pax-clone-radman

If you want to make sure there's only one main project, use the -DunifyRoot Maven property to bring any disconnected (ie. parent-less) modules under the same root project.

Feel free to try it out and feedback any issues / requests via the OPS4J JIRA site as usual - enjoy!

Rapid OSGi development : Pax-Construct 2 goes GA

2007-10-12T21:45:00.000+08:00

I've just made the new version of Pax-Construct generally available on the OPS4J repository:

http://repository.ops4j.org/maven2/org/ops4j/pax/construct/scripts/0.2.0-ga/scripts-0.2.0-ga.zip

detailed documentation for the scripts and Maven2 plugins can be found on the following site:

http://www.ops4j.org/projects/pax/construct/index.html

including an example of using Pax-Construct to assemble and deploy Spring Dynamic Modules!

http://www.ops4j.org/projects/pax/construct/examples/spring-osgi.html

Other noteworthy features:

much simpler project layout - you can even create standalone bundle POMs
transitive wrapping of third-party jars and their dependencies
transitive importing of OSGi bundles and their bundle dependencies
new scripts to help move bundles around the project
supports the latest release of Pax-Runner!

I'm away in Penang for the next few days, but will be back soon to answer questions and provide many more examples. In the meantime, feel free to comment on the wiki, or raise issues on JIRA :)

Launching Spring Dynamic Modules using Pax-Runner

2007-10-12T09:36:00.000+08:00

My fellow OPS4J'r Alin Dreghiciu has produced a really cool screencast showing how you can quickly deploy Spring-OSGi M3 using his recently released version of Pax-Runner:

http://wiki.ops4j.org/confluence/x/SwBN

You can also read more about the ongoing Pax-Runner story at:

http://wiki.ops4j.org/confluence/x/A4A6

Support for the major OSGi frameworks, flexible configuration, directory and maven scanners - what more could you want? (if yes, please mention it on JIRA!)

Alin's screencast is now linked from the Spring Dynamic Modules site:

http://www.springframework.org/osgi

well done Alin!

documentation for the maven-inherit-plugin

2007-09-24T17:38:00.000+08:00

I've uploaded some documentation for the maven-inherit-plugin in the usual format:

http://www.ops4j.org/projects/pax/construct/maven-inherit-plugin

and improved the code to use custom Javadoc tags to get the extended plugin details.

For example:


  /**
  * @extendsPlugin archetype
  * @extendsGoal create
  * @goal create-project
  * @requiresProject false
  */
  public class OSGiProjectArchetypeMojo extends MavenArchetypeMojo
  {
    // if you override member fields, remember to propagate the values using reflection
  }

Simple Maven Plugin Inheritance

2007-09-18T06:26:00.000+08:00

Pax Construct extends a number of other maven mojos from the archetype, compiler and eclipse plugins. Extending maven mojos is a bit of a pain at the moment, because plexus (the component manager used by maven) relies on javadoc comments to generate the plugin XML. Unfortunately when the parent mojo is provided by an external project, the javadoc isn't available to plexus.

At first I relied on duplicating parameters in the sub-mojo to trick plexus into creating the right plugin XML, then used reflection to forcibly update any private fields in the parent mojo.

Maintaining these parameters was a bit of a nightmare, so I developed a new plugin called the maven-inherit-plugin to help with the plugin XML. It attempts to merge the various plugin XML fragments and warns about any potential field clashes that would require reflection.

To use it in your plugin pom, add the following XML:


    <plugin>
      <groupid>org.ops4j.pax.construct.ng</groupid>
      <artifactid>maven-inherit-plugin</artifactid>
      <executions>
        <execution>
          <goals>
            <goal>inherit</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

  ...

  <pluginRepositories>
    <pluginRepository>
      <id>ops4j-repository</id>
      <url>http://repository.ops4j.org/maven2</url>
    </pluginRepository>
  </pluginRepositories>

It looks for dependencies of type "maven-plugin" and will merge the XML fragments describing their goals with any matching local goals that have the following syntax:


    @extendsPlugin {plugin}
    @goal {local-goal}

If you want to rename a inherited goal, use this syntax:


    @extendsPlugin {plugin}
    @extendsGoal {inherited-goal}
    @goal {local-goal}

For example, in Pax-Construct I extend the archetype goal into a number of sub-goals, such as:


  /**
  * @extendsPlugin archetype
  * @extendsGoal create
  * @goal create-project
  * @requiresProject false
  */

Overridden fields generate a warning at compile time and must be updated using reflection. See the main pax plugin for examples of using this technique to add behaviour to existing plugins.

Source code is available from:


    https://scm.ops4j.org/repos/ops4j/projects/pax/construct/maven-inherit-plugin

(updated to show new javadoc tags)

Calling all testers! Pax Construct v2 beta1

2007-09-18T01:08:00.000+08:00

Well, we've finally completed the move to our new home and are slowly unpacking boxes "on-demand" :)

Meanwhile, back at OPS4J I've finished a major refactoring of the Pax Construct plugin and slimmed down the archetypes to produce a much leaner project layout. The more adventurous of you might like to try out the beta version:

http://repository.ops4j.org/maven2/org/ops4j/pax/construct/scripts/0.2.0-beta1/scripts-0.2.0-beta1.zip

Be warned - the usual beta disclaimers apply! Especially since the only machine I have with Windows is still packed away, and so all testing so far has been on my macbook using Ubuntu (my main development environment). Also, the docs are woefully out of date - at this moment the code is the best documentation, but you can use -h with any of the scripts to get basic usage.

Second warning: Pax Construct v2 is not compatible with projects created using older versions, but a script is being developed to migrate projects to the new layout. However you can use v2 to create and manage new projects.

Some highlights of v2:

Transitive wrapping - you can choose to embed dependencies, or create further wrappers
Transitive import - provided dependencies of imported bundles are automatically added
Simple import management - the import list is maintained inside a single provision pom
Optional generation of Eclipse project files - use "mvn clean install -Peclipse"
Enhanced compilation - supports compiling against bundles with embedded jars
Refactoring support - bundles can be moved around, poms will be created as necessary
Improved maven mojos - can be used inside other poms to create projects for testing

Here's a couple of wrapping examples, which should be done inside a project created with pax-create-project - the first creates a bundle with embedded dependencies (use "mvn clean install" to build it) the second replaces it with a series of bundles, one per dependency:

pax-wrap-jar -g commons-logging -a commons-logging -v 1.1 -- -DembedTransitive

pax-wrap-jar -g commons-logging -a commons-logging -v 1.1 -- -DwrapTransitive -Doverwrite

A more complex example involving Spring-OSGi can be downloaded here:

Spring-OSGi deployment script (unix)
Spring-OSGi deployment script (windows)

Download the script for your OS, make sure the v2 scripts are in your path and run it - it should build and deploy a basic Spring-OSGi setup based on milestone 3, along with some wrappers and the weather sample. (note: it can take a few seconds to startup on Felix, the default framework)

There's a lot of cool stuff behind the scenes, and I'm starting on proper documentation for it this week. BTW, if you find any bugs with beta1 please raise them at http://issues.ops4j.org while I work on the docs :)

Our new home

2007-07-22T21:50:00.000+08:00

Hayfa and I are now home-owners! Picked up the keys to our new condo apartment yesterday, and spent most of this weekend discussing paints, what should go where, etc. (we're both fairly easy-going so it takes us ages to decide anything!)

Better dependency management with Pax Construct

2007-07-06T00:24:00.000+08:00

Had some really useful discussions during the OSGi Community Event in Munich about wrapping complex artifacts such as Hibernate3. The next drop of Pax Construct will try to handle dependencies for you as much as possible (automatically embedding / wrapping / importing them as required) so with one command you can drag an artifact into your OSGi project without having to repeatedly deploy or compile to track down those annoying missing dependencies.

Also planned: OBR support to search for artifacts based on your bundle's imports :)

As ever, let me know via JIRA or email if there's anything that would make OSGi development that little bit easier!

OSGi Alliance Community Event talks now online

2007-07-03T04:28:00.000+08:00

My talk from the 2007 OSGi Alliance Community Event is now online:

http://www2.osgi.org/wiki/uploads/Conference/OSGiCommunity-McCulloch.pdf

along with slides from all the other talks - well worth perusing.

http://www2.osgi.org/Conference/2007CommunityEvent

Guice-OSGi 0.1.0 released

2007-06-23T16:09:00.000+08:00

FYI, I've just made an initial drop of my Guice-OSGi laboratory project:

http://wiki.ops4j.org/confluence/display/ops4j/Guice-OSGi

org.ops4j.guice-osgi.core-0.1.0.jar
org.ops4j.guice-osgi.core-0.1.0-javadoc.jar
org.ops4j.guice-osgi.core-0.1.0-sources.jar

which lets you use Guice to access / register OSGi services - for example:

@Inject
@OSGiServiceRegistration
ExampleService exported;

would register the object injected into 'exported' as an OSGi service, and:

@Inject
@OSGiService
ExampleService imported;

would inject a proxy into 'imported' which delegates to the OSGi service.

example (use 'mvn clean install pax:provision' to try it out)

It's capable of lots more (custom LDAP filters, injected listeners, etc.) but I have a flight to catch in a few hours and need to finish my packing :) The integration tests checked into subversion contain more examples.

It doesn't do everything Spring-OSGi does, but then again it is only one bundle of ~500k ;)

(PS. I've also released 0.1.6 of the Pax Construct tools - busy week!)

The dreaded disk0s2: 0xe0030005 (UNDEFINED)

2007-06-12T20:57:00.000+08:00

I've had my macbook for nearly five months and use it as my primary dev box. Last month I took it with me to Sweden to run some OSGi tutorials - before the very first session I calmly closed the lid, wandered over to the conference room and opened it up to see... nothing!

People were already wandering in so decided to do a quick reboot - but instead of the reassuring apple logo I now saw a flashing question mark folder (gulp). Luckily the tutorial was available on the intranet (FYI, it's based on Pax Construct) so I was able to grab a spare laptop and continue.

Anyway after the tutorial session I absentmindedly turned on my macbook, which now started ok!

So is this a new mac feature, auto-repair? Sadly not... since then its behaviour has been erratic - occasional beach-balls, looking like the system had frozen only to return after a few minutes. Tried turning off spotlight indexing (nice performance boost) which helped for a bit but the problem returned. Tried a full archive, erase and re-install with minimum setup which I thought had nailed it, but this weekend my macbook went totally rosak :(

No hard disk, nothing... nowhere to reinstall MacOSX, no chance of recovering data - thankfully I still had the full image backup from a few days ago (plus most of my work is online these days).

So my macbook is now at the local Apple support centre and I'm back to using my trusty Linux box that I built from scratch (and ironically contains a still-working HDD I rescued from an ancient Dell laptop and now use for temporary storage).

So here's the MOTD... if you see any errors like the following in your system log:

disk0s2: 0xe0030005 (UNDEFINED)

make sure you have any critical data backed up and get your macbook checked out asap.

Pax Construct 0.1.5

2007-05-23T16:24:00.000+08:00

Hi folks,

By popular demand I've released Pax Construct 0.1.5

http://repository.ops4j.org/maven2/org/ops4j/pax/construct/scripts/0.1.5/scripts-0.1.5.zip

This release has the following improvements:

* simpler project layout
* support for adding repositories, removing bundles, embedding jars
inside bundles, and using bundles (ie. inter-bundle dependencies)
* better error checking and recovery

that makes it a lot easier to construct more complex OSGi projects.

Remaining issues have been pushed to 0.1.6, which is targeted for
mid-to-late June, and will include the project snapshot feature along
with (hopefully!) more documentation and samples.

Please let me know if you have any problems using this new release.

--
Cheers, Stuart

Giving a talk at the OSGi Alliance Community Event

2007-05-23T11:29:00.000+08:00

Just found out that my talk on using Maven to build OSGi projects has been accepted for the "short talks" section of the OSGi Alliance Community Event!

So, now there's even more reason to attend the event - if only to ask difficult questions / heckle ;)

Convert local Maven repository into remote mirror

2007-05-09T17:13:00.001+08:00

Almost finished my round of OSGi tutorials in Malmo, Sweden. It's been a busy time, last weekend I had two sessions back to back from 0830 to 1900! Things are a bit quieter now, so I'm going to spend time on the 0.1.5 release of Pax Construct, improving it based on feedback from the tutorials. I'm also going to add a command to create a template of a bundle that embeds a jarfile, which should make various people happy.

Anyway, on to the real topic of this post - in creating the tutorial I wrote a couple of useful scripts which let you convert your local Maven repository into a remote repository, by fixing up the necessary maven metadata and adding SHA-1 digests. You can grab the scripts from my OPS4J page at http://wiki.ops4j.org/confluence/display/~mcculls/%21sh.

I used these scripts to create an offline repository for the tutorial - by just cleaning out my local repo, running through all the exercises, copying the local repo to another location and running the scripts to add the missing metadata (see example on the !sh page). I also provided a modified settings.xml file which added mirror repos relative to the maven installation (such as file:${M2_HOME}/../../artifacts) for all the main repo ids.

This mean people could work the tutorial offline, and also meant that even when online the network wasn't hammered by everyone downloading exactly the same set of artifacts... the only downside is the extra work keeping the mirror up-to-date.

Guice and OSGi

2007-04-26T13:00:00.000+08:00

I recently wrote a patch for Guice, which adds OSGi metadata to the jarfile and fixes some classloader issues when running on OSGi. Just apply this patch to the current Guice trunk (and copy the attached bnd-0.0.130.jar to the lib/build folder) and do "ant clean dist".

You can now take the Guice jar from build/dist and use it in any OSGi framework - there's an example over at OPS4J:

https://scm.ops4j.org/repos/ops4j/laboratory/users/stuart/peaberry

( btw, peaberry is a simple entity framework to test Guice and AOP on OSGi ... it only provides partial entity bean support, hence the name: Peaberry ;)

OSGi Alliance Community Event

2007-04-24T22:09:00.000+08:00

Should be interesting - I'm thinking of going, as I'll be in Europe for June/July.

Quick OSGi projects using Maven archetypes

2007-04-23T02:45:00.000+08:00

Have you ever wanted to try OSGi, but found setting up the build and working out the manifest too much of a chore?

If so then help is at hand - over the last few months, I have been developing a set of Maven archetypes and plugins to automate much of the manual work required in creating an OSGi project. Recently I also provided Windows batch files and Linux shell scripts to make it even easier:

http://wiki.ops4j.org/confluence/display/ops4j/Pax+Construct

All you need is Maven2 and a Java5 runtime - the best part is the OSGi manifest attributes are automatically calculated for you by Peter Krien's wonderful bnd tool, connected to Maven by the maven-bundle-plugin from the Apache Felix project.

For example, the following commands would create a simple skeleton OSGi web application ... and deploy it to Equinox:


    pax-create-project -g simple.project -a osgi-web-app

    cd osgi-web-app

    mvn install

    pax-wrap-jar -g javax.servlet -a servlet-api -v 2.5
    pax-import-bundle -g org.ops4j.pax.logging -a api -v 0.9.4
    pax-import-bundle -g org.ops4j.pax.logging -a jcl -v 0.9.4
    pax-import-bundle -g org.ops4j.pax.logging -a slf4j -v 0.9.4
    pax-import-bundle -g org.ungoverned.osgi.bundle -a http -v 1.1.2
    pax-create-bundle -p my.osgi.code.myBundle -n myBundle

    mvn install pax:provision

all you need to add is the internal application code ;)

Bali 2007

2007-02-27T18:19:00.000+08:00

Photos of our recent trip to Bali - we set off on Valentine's day (along with Hayfa's parents) to Jimbaran in the south of Bali, and spent most of our trip enjoying the culture and scenery around Ubud. Had a really good time - many thanks to Pak Gusti for showing us round!

My new macbook

2007-02-10T18:31:00.000+08:00

I've always wanted to try out a mac, and the recent batch of Intel Core 2 Duo macbooks really caught my eye. However, I managed to resist the temptation last year ... as my wife Hayfa kept reminding me, we didn't need more computers cluttering up the house (we already have a dell laptop and an AMD64 desktop that I built in the UK).

Anyway, recently I moved to a new job (working on OSGi stuff) and this triggered a new bout of window ...err... mac-browsing. I'd been looking at the 2GHz mid-range model, but it wasn't in stock in KL. Then one weekend when Hayfa was in Penang (funny how I buy these things when my sayang isn't around) I saw an advert for MacCity in Cineleisure - RM3999 for the basic model for the first 10 customers between 3 and 5pm, a saving of RM400!

So I drove to Cineleisure, parked, wandered over to the store just before 3pm, mulled things over a bit, decided to queue and got the next-to-last one!

I'm very happy with my macbook - didn't take long to get used to the single mouse button (even starts to make sense!) and the mac command key. Even happier once I got fink and iTerm installed - in fact, it's now replaced my development machine at work!

Hayfa was pleased with my purchase in the end, because we don't have to fight over using the dell while we sit on the coach ... and it didn't take long (I think under an hour) for her to 'persuade' me to add a login for her on the macbook :)

So... if anyone wants a dell, let me know ;)

Spring Flowers

2007-02-10T17:44:00.000+08:00

A bargain at only RM16 from IKEA :)

I miss snow

2007-02-09T17:07:00.000+08:00

My parents just sent me this photo of the view from their house, brrrr...

Finally ... photos from our trip to Indonesia!

2006-11-27T10:56:00.000+08:00

After promising and promising to upload the photos from our recent trip to Indonesia, my wife and I sat down this weekend and went through labelling and selecting images - here is the result of our efforts, enjoy!

Indonesia 2006

Sun open sources Java under GPLv2

2006-11-13T14:09:00.000+08:00

Amazing news ... Sun is going to release Java under the GPL! InfoQ has the full scoop at http://www.infoq.com/news/2006/11/open-source-java along with some interesting observations on whether classes extending a GPL'd java.lang.Object are a derivative work (thankfully they aren't - phew).

Selamat Hari Raya Idul Fitri 1427 H, Mohon Maaf Lahir Batin

2006-11-06T11:12:00.000+08:00

Back from visiting Indonesia for Raya - we went to Padang and Bukittinggi in West Sumatra, where my mother-in-law's family live. My wife's lineage is Minangkabau, which is matrilineal, so when we have kids they'll also be Minang - how cool is that! Everyone was very friendly and interested to meet the new 'Inggeris' addition to the family. I learnt so many words in two weeks - much more than in Malaysia, mainly because not many people spoke english over there (older people can understand some dutch/german, as it used to be a dutch colony).

Food was fantastic, but oh-so-more spicy than I'm used to in KL. We had rice at every meal, even breakfast, along with various dishes like Rendang, Dendeng (like beef jerky with hot chili) and Cincang. We even managed to bring back some smoked eels, which smell horrible but taste great.

More to come later... hopefully with some photos!

Google Sitemap for Blogger Beta (was solved, now broken)

2006-10-18T10:57:00.000+08:00

I've been trying to submit my Blogger site to Google for a few days now, and was stuck at the 'Add Sitemap' stage. I couldn't publish my own sitemap directly to the root folder because it's hosted on blogspot, so I was hoping to use the feed URL:

http://mcculls.blogspot.com/atom.xml

Unfortunately, the beta version of Blogger uses a newer version of the Atom format which Google Sitemap doesn't like. Thankfully there is a simple solution which I found while searching Google groups ... just use the RSS feed instead:

http://mcculls.blogspot.com/rss.xml

it's as simple as that :)

... at least it was until Blogger Beta changed over to the REST style feeds at /feeds/blogid/posts/default. The RSS version is available by using the ?alt=rss parameter (/feeds/blogid/posts/default?alt=rss) but for some reason the top-level rss.xml file redirects to the atom format!

Footy Futsal

2006-10-15T00:24:00.000+08:00

Just got back from Footy Futsal in Taman Megah - lots of fun and exercise as usual, but have to play in the evenings at the moment as it's fasting month. My wife and I had gone to Mid Valley earlier on in the day to recycle the mountain of paper and plastic that we'd accumulated over the last few months (including far too many Dunkin' Donut boxes!).

After breaking fast with kurma (dates) we prayed Maghrib while the Surau was relatively quiet. Most people were waiting to break fast in the various restaurants - it was weird seeing row on row of tables with steaming hot food, with everyone checking the time on their mobiles.

We had hoped to eat in Chili's, but by the time we got there the waiting time was 1.5 hours! Our original plan was scuppered by their no reservation policy :( Oh well, we managed to get seats at a nice italian instead, and had plenty of time to let the food settle before the futsal.

Time to finish this post, so we can read a bit of the Qu'ran before going to bed ... have a religious class tomorrow at Al-Khadeem led by Ustaz Hussein Yee, who gives very thoughtful sermons.

Task orientated Java development

2006-10-14T13:58:00.000+08:00

Yesterday I stumbled upon a neat Eclipse plugin called Mylar which helps you manage tasks: for example you're working on a new module, but suddenly need to track down and fix a bug in another part of the project. With Mylar you can jump into the new task, safe in the knowledge that your previous GUI context (ie. open files, layout etc.) is stored under the old task. If you find the bug belongs to another developer, you can even share the relevant context to save time.

It also keeps track of how long you spend on each task, which will keep micro-managers happy :)

The site I was surfing when I saw Mylar is called InfoQ, and so far it's been a really good source of the latest news and innovations in the Java/Enterprise world. It also has one of the best Web2 interfaces I've seen this year where the videos sync with the slides - understated, but helpful.

ssshh... Pisang Quiet

2006-10-14T13:13:00.000+08:00

After several months of playing around with blogger settings, and somehow never having the time to write down my thoughts (or write up, depending which hemisphere you're in) I finally got bored of choosing a colour scheme and decided to start posting.

So... 'pisang quiet' ('peace and quiet' for those of you who enjoy malay+english puns, 'quiet banana' for those of you who like bananas) is my new blog, after my last one reached the heady heights of 11 posts. There have been a lot of changes since then - I'm now married to Hayfa, and we're living together in KL.

Married life is really good - my isteri and I went to Terengganu for our honeymoon and tried snorkelling for the first time: I normally keep to my depth when swimming, but my wife helped me overcome my nerves and explore further out at sea (the life jacket helped too!). It was so cool seeing herds of fish sweep majestically across... sorry, wrong vacation. Seriously though, the trip to Redang Lang Tengah was amazing - soft white sand, clear seas with brightly coloured fish, and my sayang at my side :)