Re: [equinox-dev] Luna - programmatically alter bundle classpath

[Thomas Watson <tjwatson@xxxxxxxxxx>]

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



Laurent Goubet ---10/11/2013 05:00:28 AM---Hi all, For the Acceleo project, we dynamically deploy workspace projects into

From: Laurent Goubet <laurent.goubet@xxxxxxx>
To: equinox-dev@xxxxxxxxxxx,
Date: 10/11/2013 05:00 AM
Subject: [equinox-dev] Luna - programmatically alter bundle classpath
Sent by: equinox-dev-bounces@xxxxxxxxxxx

---

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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev