This is absolutely possible!
Look into the OSGi extender model for the general mechanisms.
It sounds like you want to create an extender which registers services on
behalf of your resource bundles. Resource bundles only have to have a
manifest entry advertising that they wish to be processed by your extender,
and the system will hand them to you for processing. You can then put your
resources in these bundles along with enough meta-data to describe how
those resources should be handled, then have the extender figure out what
to do with them.
For an example of an extender which performs a similar function you can
look at the enRoute web server extender, which automatically publishes
static resources as web resources with no code required.
On Sat, 8 Apr 2017 at 19:08 <list+org.o...@io7m.com> wrote:
> Hello.
>
> As I've previously explained, I'm developing a game and am using OSGi
> as the foundation. We want to encourage third-party additions to the
> game and are therefore publishing APIs and building the whole thing as
> a plugin/service-based architecture from the beginning.
>
> Some plugin bundles will contain executable code, but others may not
> contain any. Examples of bundles that probably won't contain code
> are bundles containing game data such as sets of audio files, sets
> of graphics files, level data, etc. Regardless of whether or not a
> bundle contains executable code, I want it to be able to participate in
> all of the things that make OSGi great: Proper versioning, dynamic
> loading/unloading, and so on. It's not clear to me how I can achieve
> this though; it seems like I'd need each bundle to unconditionally
> include some compiled code, the only purpose of which is to provide
> something that can register itself as a service in order to participate
> in something like the whiteboard pattern.
>
> Consider something like an audio "theme" for a user interface. The game
> might define an API like:
>
> interface SoundThemeType
> {
> AudioStream buttonClicked();
>
> AudioStream scrollUp();
>
> AudioStream scrollDown();
>
> AudioStream alert();
> }
>
> A bundle that provided a set of sounds comprising a new theme for the
> user interface would then have to provide an implementation like:
>
> @Component
> public final class ExampleSoundTheme implements SoundThemeType
> {
> public AudioStream buttonClicked()
> {
> // Return an audio stream from the bundle's own resources...
> }
>
> ...
> }
>
> No doubt the actual implementation of the ExampleSoundTheme type could
> be pushed up into an abstract superclass and provided by the game
> itself, so the implementation in the bundle would end up being
> something trivial like:
>
> @Component
> public final class ExampleSoundTheme extends AbstractSoundTheme
> {
> public AudioStream buttonClicked()
> {
> return super.sound("/button_clicked.wav");
> }
>
> ...
> }
>
> However, as trivial as the above could be, it still requires an editing
> tool to compile some Java code and include it into a bundle. This means
> that non-technical users that just want to make a simple sound theme
> have to be exposed to code (even if just indirectly). It would be much
> nicer if those users could simply create a file, let's call it
> "theme.txt" that looked something like:
>
> buttonClicked: /button_clicked.wav
> scrollUp: /scroll_up.wav
> scrollDown: /scroll_down.wav
> alert: /boom.wav
>
> ... and the editing tool would insert information in the OSGi manifest
> that would, when the bundle is loaded into the game, result in an
> implementation of the SoundThemeType API being created and registered
> as a service using the given theme.txt file as a data source. To
> reiterate: The bundle just contains theme.txt, a few .wav files, and
> obviously an OSGi manifest. No compiled code.
>
> Is there some way I can achieve this pleasantly?
>
> M
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
