Hi Lindsay, see my comment below.
Am 15.03.2011 um 01:40 schrieb Lindsay Smith: > 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. > Maybe I am stupid, but does each Java-file not contain package import statements? import foo.bar.*; import com.bar.myClass; ... Here are some alternatives to get those parsed: - You could write a dumb parser in Java - The Eclipse JDT project does provide an access to the Java Abstract Syntax Tree (AST). There is also a nice GUI: http://www.eclipse.org/jdt/ui/astview/view.gif - And if you want to stay away from Eclipse, you could (mis)use CheckStyle (which implements a Java-Sourcefile Parser based on ANTLR) http://checkstyle.sourceforge.net But I'm sure I missed something in your story. Cheers, Siamak > > > Cheers > > > > Lindsay > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev -- Dipl. Inf. (FH) Siamak Haschemi Humboldt-Universität zu Berlin Dept. of Computer Science Room: III.417 Rudower Chaussee 25 12489 Berlin, Germany +49 30 2093 3121 (phone) +49 30 2093 3112 (fax) [email protected] Website: http://informatik.hu-berlin.de/~haschemi Private Website: http://www.haschemi.org Xing profile: Siamak_Haschemi Skype: siamak.haschemi
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
