Re: [forge-dev] OSGi prototype

Having trouble getting JDK 1.7.0 on my machine... did you use 1.7 or will 1.6 suffice? ~Lincoln On Mon, Oct 15, 2012 at 3:35 PM, Paul Bakker <paul.bakker.nl(a)gmail.com&gt; wrote: > THE zip contains a eclipse plugin site. Configure it as such in the eclipse install wizard. > > Sent from my iPhone > > On 15 okt. 2012, at 21:01, "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com&gt; wrote: > >> 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(a)gmail.com&gt; 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.... >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev