Something on the 'OSGI thesis' topic piqued my interest - he mentioned 'source bundles' where a bundle contains java source that is compiled to form the executable part of the bundle. That interested me because we do something similar in my project and I wanted to share the details to see if anything similar is being done elsewhere.
My project is a web-based application platform, where applications are defined by metadata, and can include java source. The platform reads the metadata and compiles the java source as part of loading the application. It's all dynamic, so we have a web-based IDE for defining application components, editing Java etc, and the platform recompiles it when needed. Using OSGI for the isolation of each applications means we can insulate the applications from the environment that the platform is running on, making it much easier to move applications between servers that may be running on different java versions or web containers. We switched to using OSGI under the hood because we saw the benefit of isolating each application using the OSGI class visibility system. The classloader used to compile the source for each application comes from a bundle that we dynamically create (using tinybundles) based on metadata defined in the application. Basically what we do is create a bundle whose manifest is determined by the application metadata, then use the classloader of that bundle to compile the java source. The resulting class files are used to create a bundle fragment that is attached to the first bundle we made, which brings the compiled classes into that bundle. What's interesting to me is how the system does or does not fit in to the OSGI world view. The thing about all the OSGI tools (like bnd) is that they generate manifests based on class files by inspecting the packages required by the classes. We can't do this because we don't have any way of working out which packages the java files need for compilation until after we've compiled them, which is obviously too late. The manifest that is used in the bundle that supplies the classloader for compilation therefore has to be very general. Our applications always use certain APIs that are defined in other standard OSGI bundles in the system, so what we have to do is use require-bundle to ensure that during compilation all those packages will be there. In addition, we have to import all the standard java packages. The application metadata can also specify specific additional imports that it knows it needs. I know this is against the OSGI grain of only importing what you need, but I don't see any way around it. I guess it's kind of similar to the way that OSGI bundles are built on the command line - you still have a very large set of classes available when you compile java source, then bnd comes along and makes the minimal list of packages to form the manifest. Eclipse takes the other route, which is to force you to say up front what your manifest imports, and uses that list of packages for compilation. Does anyone else have experience doing this kind of thing? Any other examples of compiling java source to form classes used within OSGI would be great. Is there a any way to work out imports of java source files? Any other comments about the system are very much appreciated. Cheers Lindsay
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
