Google Code上の新しいプロジェクトPojo Service RegistryはJavaアプリケーションにOSGiライト（OSGi-lite）メカニズムを、OSGiランタイムの外で提供することを目的としている。
OSGiはそのモジュラリティへの強固なアプローチで知られているが、時折複数のクラスローダーの使用（自動的にバンドルをインストール、更新、削除することができるようにするために必要）が平坦なクラスパスを仮定しているライブラリとの問題を引き起こす。しかしながら、OSGi μサービスモデルを背景にプログラミングする利点は、実装やクライアントがつながるためにその実装に対する予備知識を必要としないということにある。
Pojo Service Registryの狙いはOSGiサービスモデルの利点を、複数のクラスローダーや動的なバンドルを要求することなく得る方法を提供することである。同じAPIやシグニチャが利用されるが、PojoSRでサービスを見つけるために、OSGiのような方法でエクスポートされているどんなサービスに対してもクラスパスをスキャンする。加えて、バンドルアクティベーターはスタートアップ時にクラスパススキャニングの一部として自動的に開始される。
これはOSGiライトとして言及されてはいるけれども、OSGi名前空間とAPIが使い続けられるかどうかは今後の課題である。というのも公式なOSGi仕様の一部ではないからだ。一方で、このプロジェクトから多くのプロジェクトが触発され、このプロジェクトを選択したり、このプロジェクトと協力したりしようとしていて、その中にはGoogle App Engine上のFelixの実装なども含まれる。このデモアプリケーションがhttp://pojosr-demo.appspot.com/system/consoleで利用できる。
FelixをGoogle App Engine上で動かすことは見た目ほどシンプルなことではない。例えば、GAEはスレッドを作成することができない（し、OSGiフレームワークは本来マルチスレッドである）– が、わずかな規模の小さい修正（イベント通知フレームワークを同期化することなども含む）によって、ランタイムが起動できるようになっている。
また1つの別の側面は、クラスパスがクラスパス上のJARのセットをもとに計算されるため、（Bundle-ClassPathを使っている）ネストされたどんなバンドルも解決されないということである。このことから、組み込むか、インライン化したネストされた依存性のどちらがよいかという疑問を投げかけているものもいる – 議論はあるけれど、クラスパスが平坦であるPojoSRのアプローチでは、それはどちらも意味がなく、それ独自のバンドルとして依存性を外に出すかもしれない。
PojoSRによって、完全なOSGiのやり方に進むことなくOSGi μサービスを使う方向に移行することができ、XMLファイルの内容ではなく、クラスパスの内容に適合させてサービスを提供することができる。それが正式にOSGiアライアンスによって受け入れられ許容されるかどうかが残された課題である。