Using OSGi as deployment model
Submitted by pkriens on Wed, 10/26/2005 - 16:33.
I have looked at JNode (even ran it on my PC) and I am very excited about the project. It seems like a daunting task, but the progress you have made is substantial.
As an OSGi evangelist, I wonder if you could start using the OSGi Framework, which is a standardized modularization and deployment framework, as your deployment model. JNode and OSGi look like a perfect match. OSGi is already used as the foundation for Eclipse and is now adopted by Apache as well. There are already many companies supporting this standard. It provides a very clean model to install, update, uninstall applications as well as a collaborative model to allow apps to play together. It also provides a foundation for features that you find in a MVM, except for the full isolation (which is very expensive).
I would be more than happy to help you adopt OSGi for this reason. You can find more information at the following URLs:
http://www.eclipse.org/equinox
http://incubator.apache.org/projects/felix.html
http://www.osgi.org
http://www.aqute.biz (that is me)
http://www.knopflerfish.org
And many more on Google.
Hope this helps, kind regards,
Peter Kriens
- Login to post comments
OSGI Example
Hi People,
i am new user of Osgi and working with eclipse.I need some more example to practice.If u know about any example.I have already done all example of oscar osgi.But i didn't get any result.pls let me know.
thanx
That's music to my ear
Hi pkriens,
You proposal is music to my ear. Actually, I've proposed that about two (?) monthes ago. I'm glad to see the same idea be proposed again, and I'd like to have a talk with you about this in more details. You may contact me at mabo@ios.cn. I'm waiting for your mail.
Birkey Ma
----------------------------------------------
Beijing, China
----------------------------------------------
Things should be made as simple as possible -
but no simpler. (Einstein)
other interesting links
I discussed with enrique about OSGi R4. Here is the links he gave me :
and finally, the Confluence site for Felix
Fabien
wikipedia site
Today, I found an entry about OSGi in wikipedia.
It contains the history of OSGi and also has some urls for documentations, specifications and implementations...
Fabien
my blog (in english and french)
Hi
Hi Peter, thanks for all the links.
I think OSGi is certainly a good direction for JNode, especially since the current plugin framework is so close to where Eclipse came from.
There is always a but. For me there is a lot of fuss about the licensing issues regarding OSGi. Can you explain that?
Ewout
OSGi and Licensing
Well, the easiest route is to use one of the free implementations. Eclipse is EPL, Felix is Apache and Knopflerfish is BSD.
The OSGi Specification has a license to use it to build implementations and use them. There are no fees involved. The license is the standard disclaimer, protection of the OSGi namespace, and warning about potential unknown patent infringements. The OSGi APIs are also distributed in a JAR file that has an EPL license (EPL is that changes must be returned).
If you go to OSGi, I would love to help you. It would be fantastic if you could split all the APIs in bundles so you can start really small (CDC like) and grow to J2EE by just downloading bundles. This obviously requires a lot of discipline. I looked at JNode because I need a very small device running just Java (I am trying to get the NSLU2 to run Java in 8Mb flash). In its current incarnation, it is too big.
Kind regards,
Peter Kriens
Well, I must say a move
Well, I must say a move towards the OSGi deployment model and the service platform in general would surely be appriciated.
Maybe it's time to bundle some interessting java projects, such as OSGi (Felix/OSCAR, Equinox, KF,...) JNode, GNU classpath, kaffe, ...
If we could build an alliance where a java based OS, with OSGi in its core, a solid VM, and a state of the art standard libraries implementation are integrated into one, open source project, I think we'd get alot of supporters. The main benefits I see for each part are :
The JVM's/standard libraries lack a deployment model,
OSGi lacks resource isolation,
The java oses lacks standardized software components (Applications or services, like http, loging, ...)
Furthermore we'd have a scalable system. Of course bringing together such a large group and so many communities is not to be underestimated, so maybe, we just need to start integrating two (JNode and OSGi). I'm also willing to help, since I feel like an OSGi evangelist too, (well a non-official one
.
Greets,
Nico
Still active?
I feel sorry about pushing a thread that hasn't been active since late 2005, but it seems important to me to ask, whether this "move", this idea stagnated or has been canceled for some reasons. I see that JNode is not very active, since the last post in Core Discussion forum is the one in which I stated this issue 9 weeks ago. And there's nothing, nothing but some "Yeah, that would be nice" posts, all in the same week.
Obviously this idea meets with approval and with combined forces (as I'm not very familiar with the JNode codebase) it would be possible to achieve this idea, this dream of a scalable, open-source, managed-code, modular, Java-based OS. I won't bring in examples for what this is good in this post; I think this has already been mentioned by me and others in the JNode forums.
Apart from that obvious benefits the JNode platform would even become more famous and easier to understand when adopting a really modular design. JNode does have a plugin system already, but it is a half-way copy of Eclipse's plugin system, which, in fact, is OSGi. Today JNode uses a whole bunch of subprojects with 36 source folders. What way a new developer would ever understand this in an acceptable time span?
I feel sorry about pushing this issue again and again, but I and others obviously see the massive opportunities this may give.
rgds Farok
such things take time ...
... and are more likely to break things that took us time to make them work.
Again, I am not saying we shouldn't move to OSGI but it should be done in small steps with checkpoints between each steps.
No matter if we will or will not move to OSGI, there is one thing that should be done before in my opinion : using maven to build JNode.
That's why I started an experiment here. It lead me to remove some cycles in dependencies between JNode plugins because maven refuse to build. It's a work in progress : I am not yet able to compile the pure java part of JNode.
That work is a good thing because it allows to fix some issues earlier (I have no idea how OSGI handles cycles in dependencies) and there is a maven plugin to convert an artifact to an OSGI bundle. Of course, it won't make all the job of migration to OSGI.
Fabien
my blog : en français, in english or both
I would contribute if there was any appropriate documentation
As far as I know OSGi is not able to resolve cyclic dependencies but neither Maven is. Migrating to Maven therefore already is a step on the way of migrating to OSGi as the plugin system.
And keep in mind that the JNode plugin system is clearly influenced by the Eclipse's OSGi implementation. There are plugin descriptors which are manifests in OSGi and the extension API can be adopted either using original Eclipse source code or writing it yourself in an eclipse-compatible manner to allow execution of existing bundles using this feature.
Also, when you look at the manifest files of the plugins in all/build/plugins you will see something like this:
(Btw., do you have code tags?)
---BEGIN---
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 16.3-b01 (Sun Microsystems Inc.)
Bundle-SymbolicName: charva
Bundle-ManifestVersion: 2
Bundle-Version: 1.0.1
---EOF---
Bundle-SymbolicName and Bundle-Version are already manifest headers that are used by OSGi.
As I looked at the sourcecode of org.jnode.core.plugins I saw many similarities to OSGi (I ported OSGi to php a few weeks ago, so I almost know every interface of org.osgi.framework and org.osgi.framework.launch by heart), but I was not able to do the changes, because I couldn't actually figure out where to start. Maybe this is a result of poor class naming, poor documentation or my own stupidity. When there is some resource available explaining this package, the subpackages and mechanisms used by them in detail, I might be able to create a fork of this package using OSGi. This will most likely not completely be compatible with JNode's current plugins but when ported to Maven this would be a kind of easy process, as there are those tools to do the conversion to OSGi bundles.
But when using this approach it is most likely that none or few of OSGi's special features are used by the plugins. Therefore taking the full advantage out of this process is kind of radical approach, but might give some unique opportunities that might make JNode more easy and fast to develop. As you are experimenting with Maven, and previously introduced the project-concept, you see that modularization is necessary to keep such a large project maintainable in a way. But as JNode develops, dividing it into Core, UI, FS and Shell won't fit and it honestly doesn't today. An operating system is a huge project a single man cannot look over in a reasonable timespan and this might explain the sad fact that JNode does not really seems to grow, as there are simply not enough developers able to contribute. The ONLY solution I can imagine, except from using open standards, which is always a good thing, is to use abstraction and Java is somewhat predestinated for doing so. Imagine you have a bundle called org.jnode.fs that provides some basic interfaces for file systems and you can expand them by simply copying a jarred bundle to a deployment directory on build, or by installing it runtime, that provides the implementation of that interfaces. You don't have to know JNode's core or GUI or other FS implementations for doing so, you just code against interfaces. Not to mention live-/hot-deployment of such libraries which would be a very large step forward in operating system design.
As I mentioned, I would be willing to do some of the changes myself when I could find some resource or some kind person willing and able to help me doing so. Making a system that you did not completely understood easier to understand is kind of a difficult process