We Keep Coding

Build Very Simple Minimalist Java Plugin Container

I'm working on an app where I'm in need of building a very small and minimal plugin container.
Below are the things I'm trying to achieve.
Application is divided into smaller plugins packaged as Jars.
Plugin container should get them and load all jars.
Each plugin should not interfere with other plugins and should run on it's own along with it's dependant libraries. Basically all plugins should be isolated at runtime.
I tried using OSGI container, but it adds high complexity. Also many of the third party libraries which are not compatible with OSGI creating problem which is taking lot of time to debug. Also checked out Spring Boot, JPF etc. and not very interested. So thought of using very small homegrown plugin framework.
I have no clue on how to do and where to start. Please anyone can point me in right direction where I can get detailed information on this.
Thank you in advance.

If you truely want something minimalistic, have a look at Java's ServiceLoader class.
Here's a tutorial.

Play-Java OSGi Embeddable?

Context
I have a set of bundles implemented by myself running on Felix (an implementation of the OSGi Framework). All bundles were written in Java.
Question
With the above scenario I decided to implement an MVC Application using the Play Framework for Java, my question is, how can I use my bundles running on Felix? Those bundles represent libraries that I need to develop my application.
I though about putting my Play App inside Felix, but that doesn't seem to be possible?
Does anyone had this problem before?
Thanks.

I believe your question is vague....Any way, I will try to answer with what I had understood.
Using Maven[I took this assumption].
Create a parent maven project , which should server as your application frame.
Create Maven Modules Under this parent modules, which are all your libraries..
Start OSGI Embedded Framework inside your application frame
Expose API in application frame to install , update and Stop you bundles.
Create Bundle Activators in Each Libraries modules.
Use BND tool to create bundle
Then Start your application. Install bundle and enjoy.....

What is a good way to structure a library which should work in OSGI- and non-OSGI environments?

I am writing an application which runs in an OSGI environment.
Now I want to extract some code and put it in separate bundle/jar file to reuse it also in other applications (both, OSGI or non-OSGI).
My goal is to remove any dependencies to the OSGI environment classes, because it should also run in other apps which do not have all the jars of the various OSGI frameworks (e.g. Equinox). But at the same time I would like to register an OSGI Service in the OSGI environment if the Application is an OSGI app.
I have already separated the code and the only remaining piece of OSGI-dependent code is currently my Activator class which registers some class as an OSGI Service:
context.registerService(MyServiceInterface.class.getName(), new MyServiceImpl(), new Hashtable());
To remove the dependency, I think about the following:
I remove the Activator and OSGI dependencies from my bundle1
I create another bundle2 where I move the Activator
In the end I have my bundle1.jar which only has a Manifest.mf file to make it OSGI-ready, but there is no code anymore depending on OSGI framework classes.
I have another bundle which only belongs to my current application which imports bundle1.jar and has the only purpose of registering the MyService.class on the OSGI container using an activator.
Is this approach ok or are there any other best practices?
Is registering a service in the OSGI environment good practice or is this something which always the host application should be responsible for?

Why not just leave the activator class in your bundle. When run in a non-OSGi environment, the activator class will not be called. When run in an OSGi environment, it will. Isolating you OSGi dependencies to the activator is a fine strategy.

In most cases you can publish your service without Activator. Take a look at OSGI Comunity Wiki and Equinox example.

Another approach is to use blueprint. At least in simple cases it allows to have no dependencies to OSGi at all. For real world cases you typically need at least some OSGi APIs but it is no problem to leave them simply inactive in the non OSGi case.
You may also want to try PojoSR. It allows to use Activators and OSGi Services outside OSGi. We started to use this in Apache Camel to test OSGi code.

Using Spring-DM would help remove code dependency to OSGi. Your bundle wouldn't need an activator and the service can be exported from the spring-dm config xml. However, this does add a lot more runtime dependencies, but no compile dependencies are needed.

Design a Plugin based java application

I'm trying to make a plugin-based application which means, besides the basic framework, other functionalities should be added with a plugin style.
The majar problem of such system, i think, is how to load new plugins at the runtime. I don't want to recomplie the whole project when a new plugin installed. Just like Eclipse, after new installation of plugin, the user only need to restart it.
So my first idea about that is using java reflection to load the class at the runtime. there might be some plugin configuration files, the system reads them and load the plugin classes with reflection. Maybe i can use the spring framework as well, because its Inversion of Control is just match my request.
Another idea i'm investigating is using the ejb container. when the plugins are ejbs, i can just pack them into jar and deploy them in an ejb container, then i can use jndi to access them. but it only works when the plugin are ejbs.
anyway, i'm a rookie in system design. so i post this topic and want to hear of your opinions.
btw. is there any good book about system design you want to recommand?
thanks alot in advance!

You may first look at OSGI and his implementation (Equinox for Eclipse and Apache Felix) but it would be easier if you give us more information of what you are trying to do.

Plug-in to solve what problem?
Designers of frameworks usually have deep domain knowledge that informs their design choices. Frameworks come about after two or three attempts to solve some problem; the earlier implementations give clues about how to abstract what's important into a framework.
Eclipse solves the problem of an expandable IDE (poorly, in my opinion). EJBs are transactional, distributed components that run in a container.
You've given no indication of what kind of problem you want to solve. Until you do, your ideas won't get very far.

Efficient OSGi development workflow

I work on a product composed of many bundles running as features on top of karaf. Typically our developers work on one bundle at a time. Our normal development goes something like: code, compile, copy bundle to deploy folder, test. We've also found that hotdeploy just refuses to override certain bundles that are installed as features without a server restart or a feature uninstall/reinstall, so sometimes the cycle is longer.
My question is: does anyone in the community have a better way? The way we do things works, but I feel like it's pretty slow and inefficient and I'm betting someone has come up with something better!
EDIT: I realize that I was pretty unclear in my question... We are using Equinox underneath Karaf. We also use Eclipse and Maven, although I don't know that using Maven is relevant.

Sounds like you want the dev:watch command. From the documentation:
The watch command can be used to help at developement time. It allows you to configure a set of URLs that will be monitored. All bundles location matching the given URL will be
automatically updated. This avoids the need for manually updating the bundles or even copying the bundle to the system folder if needed. Note that only maven based urls and maven snapshots will actually be updated automatically, so if you run
dev:watch *
It will actually monitor all bundles that have a location matching mvn:* that have '-SNAPSHOT' in their url.
Doing "dev:watch --help" from the Karaf shell will list its available flags and args.
Something similar is the PAX plugin
Either of these will work quite nicely if you've got the m2 maven plugin for Eclipse.
UPDATED: In my company we strive to be as TDD as possible, therefore a lot a development is done without explicitly starting Karaf. In the normal mix of unit tests we're also using Pax Exam, which is largely fantastic even when run from within Eclipse =)
This helps ensure we're not too tided to any Karaf specifics as it runs with Equinox/Felix/Concierge (so I mock out various Karaf specifics we depend on like JAAS authentication). Along with many other cool tools/functionality, it's capable of provisioning Karaf features and using TinyBundles you can even create bundles on the fly (again useful for mocking/stubbing).
Pax Exam hooks into the JUnit framework by providing a JUnit #Runner, the latest version (2) is much faster and has DSL based API, so the tests are quite concise and readable.
Using Pax Exam gives us good test coverage and short development times. Where tests are less practical or we're hunting bugs that don't surface in tests, the dev:watch command is invaluable.
In summary; IMO you should definitely drive your developments with tests (Pax Exam will slot into your existing build nicely and once you get used to it you'll find development quicker). You can start using the dev:watch command immediately, it will certainly speed up your current situation.
UPDATE 2: In answering another question I've added a maven example Pax-Exam testing a ComponentFactory. Test Driven Development is arguably the most efficient workflow available to developers today. link to question: osgi: Using ServiceFactories? and link to sourcecode: http://dl.dropbox.com/u/2465717/net.earcam.example.servicecomponent_2011-08-16_15-52.tgz

I've had excellent results using Equinox in Eclipse - even hot code replace works properly. granted, the target platform is small and we have only on the order of approx 50 bundles of our own, but workflow goes like this:
First, we have a target platform that contains all third-party and Eclipse bundles, Eclipse takes care of downloading & managing them. Then, the workspace has all the bundles of the project, grouped in 3-4 working sets. Compilation happens as usual on save, sometimes GWT needs to be recompiled, but even then the changes get picked up immediately because no deployment needs to happen - the running Equinox system uses the unpacked project folders as bundles. Running this from within Eclipse gives us hot code replace, on-the-fly changing template files, only MANIFEST.MF/plugin.xml changes need to refresh the bundle - and even then it's usually faster to just restart the framework than to type in the console.

if you use Eclipse Eclipse Libra may be useful for you. Libra can start Felix, Equinox and Knopflerfish inside Eclipse as any other server with WST. They have some youtube videos how to use it.
I also wrote some tools that can help:
An osgi bundle that picks up OSGI services that match the filter (osgitest=junit4). With that you do not write Junit classes but you can provide pre-configured objects (e.g. with OSGI Blueprint). JUnit than runs based on the annotations provided in the interface your service implements.
A maven plugin that has the following useful goals
Start a OSGI containers and deploy the bundle maven project with all of it's dependencies (which are OSGI bundles of course). The OSGI container starting is done with the help of PAX Exam but the JUnit tests are started with the help of the OSGI bundle I wrote (that runs the OSGI services you may provide).
Create a folder that contains a shortcut to all dependencies of the project (located at the maven repo or target directory of the folder)
If the projects are deployed onto the server (Eclipse Libra) I have to say only update X where the X is the id of the bundle and everything is refreshed rapidly. You do not have to re-compile the projects that are published to the server if you run Equinox in Libra as it points to the target classes folder which is refreshed as soon as you save your class or pom.xml.
If you do not publish your project onto the server but add it as a bundle in the container pointing to the shortcut folder you can also run the update command on the OSGi console after running mvn install (without the restarting of the server).
A step-by-step guide is available at http://cookbook.everit.org/
With the following method above it is possible to write tests as TDD tests and run them as part of a maven compile on the CI server.
I hope you will find these tools as useful as I do!

It depends on the platform under Karaf: Felix or Equinox.
Equinox
Eclipse has excellent (or almost excellent) support for launching Equinox with bundles of your choice. The two things you need to prepare are:
Bundles, being developed, available in the workspace as Plug-in projects
Target platform, containing the remaining bundles of the application
Such setup will allow you to easily make changes to your bundles, even runtime and easily restarting the runtime when this is required. I see Karaf as more suitable when you are developing on remote system, where the bundles are deployed via SSH or FTP or when you are using external build tools like Maven, which have ability to automatically copy the bundle in the runtime after it is built.
If you are using Equinox, this will give some extra edge over as the runtime will execute the code directly from the workspace.
Felix
Felix doesn't seem to have such support for launching from Eclipse (although there is a work toward this, tracked in this Jira issue). You can also launch it as normal Java application, but this is far from convenient. In this case, using Maven will be much better alternative. You can still setup Eclipse to take full advantage of the PDE other features, only launching will be done externally.
Summary
In summary, you can always automate everything through Maven and Karaf will greatly help you in this regard. Eclipse will give a little edge, if you are using Equinox. You should be able to have hot-code replace regardless of the method you are using, because the hot-code replace doesn't even consider OSGi at all (except in the only case, when you reload your bundle and fresh class loader is created).