Allows specification of forced exports in a separate file

[stephan]

The current mechanism for specifying forced exports in the config.ini file is cumbersome if several forced exports are needed. Therefore, we should support specifying forced exports in a separate file, with only a link to this file in config.ini.

Two things must be considered:

• What kind of path/URL can be used to link to that file?
• Should the syntax be changed / enhanced? At least line breaks will become possible, perhaps that already sufficiently improves over the current situation.

[stephan]

Implemented in r19599:

• config.ini (or system property defined as -Dotequinox.forced.exports=...) may specify a comma separated list of files, marked by @ as the first character of this property.
• File location will be interpreted relative to the eclipse installation. Recommended location would be -Dotequinox.forced.exports=configuration/forcedExports.ini, which searches for the file right next to config.ini. A variable pointing to the workspace location can not be assumed at this point.
• Syntax remains unchanged except for accepting line breaks and whitespace at the beginning/end of lines, plus accepting multiple files.

⇒ More sophisticated support is being discussed in #199.

[stephan]

For the records: The recommendation in the previous comment should of course read

-Dotequinox.forced.exports=@configuration/forcedExports.ini

The @ token is essential.

[stephan]

As of r19602 the property mentioned above has been replaced with two distinct properties:

• otequinox.forced.exports.granted
• otequinox.forced.exports.denied

New applications should thus use the .granted property instead of the old one. All properties use the same syntax, no matter whether using values inline or via a separate file.

[ruwen]

Hi!

I just tried it. It does not work: My config.ini:

otequinox.forced.exports.granted=configuration/grantedForcedExports.ini

My grantedForcedExports.ini Version 1 (this line we had once in the config.ini and it worked):

otequinox.forced.exports=org.eclipse.uml2.diagram.clazz[org.eclipse.uml2.diagram.clazz.edit.helpers;x-friends:=de.nordakademie.uml2.diagram.clazz.custom,org.eclipse.uml2.diagram.clazz.edit.policies;x-friends:=de.nordakademie.uml2.diagram.clazz.custom,org.eclipse.uml2.diagram.clazz.links;x-friends:=de.nordakademie.uml2.diagram.clazz.custom,org.eclipse.uml2.diagram.clazz.parser;x-friends:=de.nordakademie.uml2.diagram.clazz.custom,org.eclipse.uml2.diagram.clazz.view.factories;x-friends:=de.nordakademie.uml2.diagram.clazz.custom]

Version 2:

org.eclipse.uml2.diagram.clazz[	org.eclipse.uml2.diagram.clazz.edit.helpers;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",org.eclipse.uml2.diagram.clazz.edit.policies;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",org.eclipse.uml2.diagram.clazz.links;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",org.eclipse.uml2.diagram.clazz.parser;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",org.eclipse.uml2.diagram.clazz.view.factories;x-friends:="de.nordakademie.uml2.diagram.clazz.custom"]

Version 3

org.eclipse.uml2.diagram.clazz
[
	org.eclipse.uml2.diagram.clazz.edit.helpers;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.edit.policies;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.links;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.parser;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.view.factories;x-friends:="de.nordakademie.uml2.diagram.clazz.custom"
]

In all cases I get the following exception

ava.lang.RuntimeException: Illegal syntax in otequinox.forced.exports directive: configuration/grantedForcedExports.ini
at org.objectteams.eclipse.transformer.hook.OTStorageHook.parseForcedExports(OTStorageHook.java:137)
at org.objectteams.eclipse.transformer.hook.OTStorageHook.readForcedExportsFromProperty(OTStorageHook.java:105)
at org.objectteams.eclipse.transformer.hook.OTStorageHook.readForcedExports(OTStorageHook.java:81)
at org.objectteams.eclipse.transformer.hook.OTStorageHook.access$2(OTStorageHook.java:76)
at org.objectteams.eclipse.transformer.hook.OTStorageHook$1.get(OTStorageHook.java:207)
at org.eclipse.osgi.framework.internal.core.ManifestLocalization.getHeaders(ManifestLocalization.java:61)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:1021)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:968)
at org.eclipse.update.internal.configurator.branding.IniFileReader.getFeaturePluginLabel(IniFileReader.java:193)
at org.eclipse.update.internal.configurator.branding.AboutInfo.readFeatureInfo(AboutInfo.java:80)
at org.eclipse.update.internal.configurator.FeatureEntry.getProperty(FeatureEntry.java:241)
at org.eclipse.ui.internal.BundleGroupProperties.getWelcomePageUrl(BundleGroupProperties.java:195)
at org.eclipse.ui.internal.BundleGroupProperties.getWelcomePageUrl(BundleGroupProperties.java:103)
at org.eclipse.ui.internal.ide.AboutInfo.getWelcomePageURL(AboutInfo.java:298)
at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.hasWelcomePage(WorkbenchActionBuilder.java:1229)
at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.makeFeatureDependentActions(WorkbenchActionBuilder.java:1186)
at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.makeActions(WorkbenchActionBuilder.java:1004)
at org.eclipse.ui.application.ActionBarAdvisor.fillActionBars(ActionBarAdvisor.java:147)
at org.eclipse.ui.internal.ide.WorkbenchActionBuilder.fillActionBars(WorkbenchActionBuilder.java:335)
at org.eclipse.ui.internal.WorkbenchWindow.fillActionBars(WorkbenchWindow.java:3390)
at org.eclipse.ui.internal.WorkbenchWindow.<init>(WorkbenchWindow.java:403)
at org.eclipse.ui.internal.tweaklets.Workbench3xImplementation.createWorkbenchWindow(Workbench3xImplementation.java:31)
at org.eclipse.ui.internal.Workbench.newWorkbenchWindow(Workbench.java:1708)
at org.eclipse.ui.internal.Workbench.access$14(Workbench.java:1706)
at org.eclipse.ui.internal.Workbench$59.runWithException(Workbench.java:3333)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)
at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
at org.eclipse.ui.internal.Workbench$27.runWithException(Workbench.java:1361)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3378)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3036)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2293)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)

I also got the following warning in my error log view: Not loading teams for bundle org.objectteams.otequinox.aspectasker (transformerPlugin not yet initialized)

Am I doing it wrong? At least

Overall this solution still leads to trouble when a plugin is developed is more than one version.

Example:

MyPlugin? 1.0 (stable and released version) needs forced exports for some.package.a and some.package.b.

MyPlugin? 2.0 (next release, already in feature freeze) needs forced exports for some.package.a, some.package.b and some.package.c.

So I need for the same plugin different forced exports. Since equinox allows you to have a plugin loaded twice (with different versions) afaik, this could lead to trouble in a productive environment.

[stephan]

Replying to ruwen:

I just tried it. It does not work: My config.ini: otequinox.forced.exports.granted=configuration/grantedForcedExports.ini

[...]

In all cases I get the following exception
java.lang.RuntimeException: Illegal syntax in otequinox.forced.exports directive: configuration/grantedForcedExports.ini

This time the error seems to be right, please check see comment:2, the same holds for forced.exports.granted, too.

I can't find a @ character in your property definition. For clarity your definition should read:

otequinox.forced.exports.granted=@configuration/grantedForcedExports.ini

I also got the following warning in my error log view: Not loading teams for bundle org.objectteams.otequinox.aspectasker (transformerPlugin not yet initialized)

that warning is inevitable: the transformerPlugin must load the askectasker before it can start weaving aspects, so the aspectasker is loaded before aspect weaving is ready, but since it is just a normal plugin, we don't yet know, whether or not the asker itself wants to define aspect bindings, which it can't because it is loaded to early for that ;-)

=> please just ignore this warning.

Overall this solution still leads to trouble when a plugin is developed is more than one version. Example: MyPlugin? 1.0 (stable and released version) needs forced exports for some.package.a and some.package.b. MyPlugin? 2.0 (next release, already in feature freeze) needs forced exports for some.package.a, some.package.b and some.package.c. So I need for the same plugin different forced exports. Since equinox allows you to have a plugin loaded twice (with different versions) afaik, this could lead to trouble in a productive environment.

First, isn't this issue relevant for any of the techniques for specifying forced exports??

Second, your comment is right when talking about well-behaved OSGi bundles. However, most eclipse plug-ins are not well-behaved in this sense: no singleton plug-in can ever exist in different versions simultaneously (other reasons for multiple versions to fail may exist in addition).

Third, I will shortly add another comment on bundle versions at #199.

BTW: After talking to John Arthorne (developer of org.eclipse.core.resources) I'm currently trying some tricks to get the workspace-based definition of forced exports to work without interfering with the choose-workspace dialog. However, no promises at this time.

[ruwen]

Replying to stephan:

I can't find a @ character in your property definition. For clarity your definition should read: {{{ otequinox.forced.exports.granted=@configuration/grantedForcedExports.ini }}}

Ok it works now. At least we got a seperate file now. So users with linux/mac can create a symlink which points to the right file in the workspace. Of course this only works if you develop one plugin at a time, but at the moment I do ;)

Thanks for the help again!