Hi, Some comments in line - will respond to Todd a little later...
2009/3/25 Sandro Martini <[email protected]> > Hi to all, > I've a very little experience with OSGi, but i think that a primary > Pivot use case for this could be to handle a load/start/stop/reload In OSGi this is install/start/stop/update/uninstall. > module inside an application, so maybe a more simple approach could be > enough, to avoid too much heavy Pivot applications by library > dependencies and complex code for plugins/modules creation. > Maybe for this some classloader tricks could be enough ... and maybe > this simpler approach could be done as much as OSGi-compatible as we > can. > Java 7 will have these features (modules), so this could be a risk to > implement by custom code (complexity and less features). > If you're following the JSR 294 discussion (as I am) you'll see that there are people who are striving to make module support in Java 7 compatible with the existing module implementations (namely OSGi and Jigsaw), so choosing OSGi won't be a problem. > > > Although I think that OSGi is great technology, I don't see that it's > > something that pivot needs to implement, other than perhaps making it > easier > > for OTHER people to use pivot in an OSGi based application. > I think the same. There are some libraries that takes a jar and wraps inside an OSGi > bundle, someone has tried ? Eclipse has a wizard that can take Jar files and turn them in to OSGi bundles. All it really does is package them in to a single jar, and export a version controlled list of packages. OSGi allows the same package to exported with different versions and allows other bundles to choose the version of the package they want to import. Thus, jar hell is eliminated because you can be as explicit as you want about the exact version of a library you want to use. > > > >> First, I've been thinking that we might want to start thinking about > >> the concept of a "Pivot kernel" that can show the loading state of an > >> app while the JARs are loading, to eliminate the unresponsive feel of > >> the app while it initializes. > Ok, but i think this is complex, so why not for a more future (2.0) release > ? > Or, for the next try with a simpler approach, then see if/what to do > in this direction ... > > > I'm not sure if it's still a problem, but I tried once to implement an > > applet loading display using a custom classloader and ran into some bugs > in > > the classloader/sandbox interaction in the java plugin (this was java > 1.5). > Right, so we should think for a future release (2.0 or maybe 1.x) to > drop the pre-Java 6 (Update 10) compatibility, otherwise we risk to > miss some recently fixed Java features ... > > Best regards, > Sandro >
