Hi Raymond, Unfortunately there is not a better way. At least I am not able to think of one right now. The framework has a predetermined set of packages it will export from the system bundle based on the Java SE version it has detected that it is running on. The framework does not do any kind of class path scanning to determine the list of packages that should be exported by the system bundle. Any extra packages you want to be exported by the system bundle must be configured by the launcher. This sounds exactly like what you are doing. One other way you could accomplish this is by installing system.bundle fragments that are completely empty except for the META-INF/MANIFEST.MF. In the bundle manifest you would specify the exported packages. So you could have a "companion" system bundle fragment for each additional jar that is on the framework class path and each one would have something like this in their bundle manifest:
Bundle-ManifestVersion: 2 Bundle-SymbolicName: foo Bundle-Version: 1.0 Fragment-Host: system.bundle Export-Package: some.foo.stuff. some.more.foo.stuff Just an idea, but then you could put these manifests in your "external" jars and at launch discover the fragment bundle manifests and ensure that their companion is installed in the framework. You could even generate the companion (empty) fragment bundle on the fly and install it. But I am not really sure that sounds much better than what you are currently doing. You mention the osgi.frameworkClassPath property. This property is not actually used by the core osgi framework. Instead it is used by our equinox launcher to specify a specific framework (org.eclipse.osgi) jar to launch with (see http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/Main.java). HTH Tom |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Raymond Auge <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Equinox development mailing list <[email protected]>, | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |08/29/2012 11:24 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[equinox-dev] extending the classpath of an embedded Framework | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hello All, In have an application with a large number of jars. Within that application I am initializing an embedded Framework instance. Now, suppose I want to allow access to a subset of the packages available to the application which originate from the jars at hand (the actual osgi bundles deployed are mutually exclusive from the jars of the application). In other words I'd like to effectively increase the classes available by building up a classpath of jars I want to expose as packages via the system bundle. I built a mechanism (which I rather hate) which collects packages from a list of named jars, and passes this to the framework via the "org.osgi.framework.system.packages.extra" property. It's clunky and there has to be a better solution. I had then hoped the property "osgi.frameworkClassPath" defined here http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html could have solved the issue for me. However, that property doesn't seem to exist anywhere in the juno source code, or it's use is so obfuscated that I can't find where it's might be, nor is it having any effect. Am I making any sense? Thoughts on how to handle this? -- Raymond Augé | Senior Software Architect | Liferay, Inc. --- 8-9 October 2012 | Liferay North America Symposium | liferay.com/northamerica2012 16-17 October 2012 | Liferay Europe Symposium | liferay.com/europe2012 24-25 October 2012 | Liferay Spain Symposium | liferay.com/spain2012 _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
