I'm not sure why the use of a class loading hook is more intrusive than the solution you have for the Kepler release. If I understand correctly you have a bundle installed in Kepler that uses internal classes to augment bundle classpaths for specific bundles on the fly. Instead of having this bundle that uses these internal classes you could have a bundle (framework extensions) that hooks directly into the class loader of equinox.
The dev.properties file is able to specify the symbolic names of the bundles you want to augment the class path for. So it it does not all bundles in the system. You can also clear the file out after your bundles are uninstalled. But it does require the framework to be launched with the -dev option from the start. Tom From: Laurent Goubet <[email protected]> To: [email protected], Date: 10/21/2013 02:21 AM Subject: Re: [equinox-dev] Luna - programmatically alter bundle classpath Sent by: [email protected] Hi Thomas, Thanks for the info; we'll look at what's possible for us with Luna, but it seems like the "dev.properties" option requires a user action and is quite intrusive (much like the class loading hooks). Our goals with this "on-the-fly" classpath modification was to be has little intrusive as possible : we only altered the classpath when deploying the bundles, and since the bundles in question were uninstalled as soon as our action ended, this was not visible outside of our tool. On the opposite, it seems like the "-dev" change will affect all clients of the framework? Laurent Goubet Obeo On 14/10/2013 17:38, Thomas Watson wrote: Hi Laurent, Sorry for the slow response. There is no 'internal' means to change the classpath of the bundle any more in Luna. From the framework POV this is immutable meta-data tucked away in the capabilities of the module. Declared capabilities (such as the classpath) are immutable. The only way I can see this working is to use a class loading hook similar to how PDE takes advantage of the development class loading hook built into the framework. What you are doing is exactly what PDE needs to do to add extra class path entries for bundles loaded out of the workspace. Could you have the framework launched with the -dev option and point to a dev.properties file that sets the dev (workspace) class path for each bundle symbolic name in the workspace? Also, keep in mind that the framework will detect changes to the dev.properties file so you can change it without restarting the framework, but just like you do today the bundle that you change the classpath for would need to be refreshed to recreate the class loader with the new classpath. Tom Inactive hide details for Laurent Goubet ---10/11/2013 05:00:28 AM---Hi all, For the Acceleo project, we dynamically deploy worLaurent Goubet ---10/11/2013 05:00:28 AM---Hi all, For the Acceleo project, we dynamically deploy workspace projects into From: Laurent Goubet <[email protected]> To: [email protected], Date: 10/11/2013 05:00 AM Subject: [equinox-dev] Luna - programmatically alter bundle classpath Sent by: [email protected] Hi all, For the Acceleo project, we dynamically deploy workspace projects into the current Eclipse instance as bundles. To this end, we use a number of the facilities provides within the osgi bundles (PackageAdmin and the likes). This has worked fine for a number of releases, but the reactorings introduces by Luna changed that. Basically, the framework provides all necessary API to install and uninstall workspace-defined bundles in the running instance... but no API to change said bundles so that they are _valid_ equinox bundles. The workspace projects contain java source code. The compiled classes are located in the project's output directory (bin by default)... But equinox does not know that, so before installing the bundle we need to change its classpath so that equinox can be taught where to look for packages and classes. Three years ago, I asked for the opening of an API to do just that without relying on restricted classes through https://bugs.eclipse.org/bugs/show_bug.cgi?id=271761 . Really, only these two lines were causing an issue : BaseData bundleData = (BaseData)((AbstractBundle)bundle).getBundleData(); bundleData.setClassPathString(output.removeFirstSegments(1).toString ()); Since both "BaseData" and "AbstractBundle" were restricted. Other than that, this code worked fine... and it has for three years (you can also see the exact code we use on http://git.eclipse.org/c/m2t/org.eclipse.acceleo.git/tree/plugins/org.eclipse.acceleo.common/src/org/eclipse/acceleo/common/internal/utils/workspace/AcceleoWorkspaceUtil.java#n1007 , the one method which accesses restricted code is setBundleClasspath(IProject, Bundle)). However, both of these classes have now disappeared from Luna. The 'Bundle' we now have is an instance of EquinoxBundle. I haven't managed to find a workaround for these two lines of code, since I haven't seen any way (this time, even through restricted API) to alter the bundle's class path prior to refreshing it through the package admin. My question would be : is there any API means to achieve my goal (deploying a workspace-defined bundle in the current eclipse instance)? If not, is there even a mean using classes that are subject to change (such as we did with BaseData from Helios to Kepler)? Is there any plan to support such a use case? Laurent Goubet Obeo[attachment "laurent_goubet.vcf" deleted by Thomas Watson/Austin/IBM] _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev [attachment "laurent_goubet.vcf" deleted by Thomas Watson/Austin/IBM] _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
