[forge-dev] OSGi prototype

[Lincoln Baxter, III]

How do you install BNDTools 2.0 once you have downloaded and extracted the
archive.zip latest build from the CI server?

Thanks,
~Lincoln

On Sat, Oct 13, 2012 at 4:17 PM, Paul Bakker <paul.bakker.nl at gmail.com>wrote:

> Hi all,
>
> As discussed in last Wednesday meeting I created a basic OSGi based
> prototype for Forge 2.0. This is not even close to a port of Forge, but
> rather a demonstration on how the basic programming model could work for
> further discussion.
>
> The prototype contains the following:
> 1) A jline shell that can execute plugins
> 2) A plugin example using Felix Dependency Manager
> 3) A plugin using SCR annotations
> 4) A simple Facet that can be injected
>
> Note that jline is not configured properly, I didn't really look into that.
>
> Plugins are OSGi services, so they need to be registered to the service
> registry. This can be done using any dependency injection framework in
> OSGi, for the example I have focussed on Felix Dependency Manager and
> Declarative Services with annotations.
>
> A plugin doesn't need to be annotated and doesn't need to implement any
> interfaces. The only requirement is a service property "plugin" that
> defines the name (alias) of the plugin. Service properties are a standard
> OSGi services feature.
>
> The Forge shell listens to plugin registrations and de-registrations.
> Whenever a new plugin service is registered to the service registry it will
> be picked up, and whenever a service is unregistered it will be removed
> from the list of services. This is very valuable for adding/(re)installing
> new plugins while running Forge. While this is kind of hacky in the current
> Forge implementation, this is one of the very basic features of OSGi
> services. The fact that it only requires a few lines of code sort of proves
> that :-)
>
> Another important part of Forge are Facets and dependency injection of
> Facets. Facets are also OSGi services, but in this case they should publish
> an interface (that's the whole idea of Facets). In the prototype there is a
> Project interface defined in the exported api package. This interface is
> implemented and published as a service by the ProjectFacet project. Again
> I'm using Felix Dependency Manager to register the service, but we could
> use annotations as well. The Project facet is then injected into the
> ExamplePlugin (using Felix DM again).
>
> The programming model for Plugin developers is very similar to the current
> model. You define a pojo and register it to the registry using either an
> annotation or an Activator. Because we package plugins as OSGi bundles we
> do need a manifest. When using BndTools this is all generated
> automatically, you don't even have to know it's there. When using Maven you
> can use the Maven Bundle Plugin, which is also based on Bnd and does
> basically the same. As a plugin developer you just add the plugin to the
> POM (or Forge does that for you, I already have a plugin for that...) and
> that's it. No need to worry about import/exports or anything else OSGi
> related. Packaging a plugin could be done in several ways (from code,
> picking up from disk etc.). Basically you just need to install the bundle
> into the OSGi framework.
>
> As a core developer the model is very similar too. Basically you still
> just develop internal plugins and facets the same way you would today. We
> can be more strict about interfaces and versioning however. Public
> classes/interfaces must be explicitly export in the Manifest. This is a
> good thing! It's impossible to use non-exported packages in OSGi, so we can
> strictly enforce that plugins only use public APIs. Exported packages are
> also versioned. A client of a class/interface will usually import the
> package using a version range up to the next major version for example.
> Using this you can have semantic versioning, and compatibility problems
> will be more predictable.
>
> This prototype just shows the very basic model. If we agree this is a good
> model to move forward with, we should look at some more detailed
> requirements such as plugin sharing/inheritance and library usage. Before
> hacking away we should probably come up with some requirements for that :-)
>
> Running the prototype:
> The code is on github: https://github.com/paulbakker/forgeosgi.
> Note that you need BndTools 2.0 to play with the code. This is an Eclipse
> plugin that does all the OSGi related stuff. BndTools 2.0 is not released
> yet (but I'm using it daily) and you can get it from the latest build:
> https://bndtools.ci.cloudbees.com/job/bndtools.master/lastSuccessfulBuild/artifact/
> .
> After installing BndTools you can create a workspace and import the
> projects. You can run from Eclipse by opening org.jboss.forge.shell,
> right-click on forge.bndrun and select "Run as->OSGi run". This runs Forge
> in an Eclipse console which is not very useful because it messes up the
> shell. It does give you hot code replacement however. Packaging Forge is as
> simple as opening the bndrun file, go to the run tab, and click export. You
> get a executable jar file that contains everything. Hot code replacement in
> a Forge instance running in a normal terminal should also be possible, but
> we have to do some work for that (normally you would just use the Eclipse
> console). The two plugins both support a "setup" command and can be
> executed as "example setup" and "annotated setup".
>
> Cheers,
>
> Paul
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20121015/cd6093c4/attachment.html