Hi Dawn Developers,

I found a bug and would like to know what can be done. This bug appears 
in both DawnVanilla build (at ESRF) and in dViewer build (at EMBL), and 
it does not appear in DawnDiamond (at DLS). This already brings up a 
question, why our builds differ so much, so a critical bug can appear in 
one build and not in other.

The symptom is this. First I clean .eclipse and workspace folders, so 
previously cached files will not interfere. I activate java 1.7.x, and 
start DawnVanilla for example. There is no exception, no error message, 
and the product has the half of menu (File, Edit, Window and Help), I 
believe it is a critical bug. After this first run, if I start any kind 
of Dawn (even DawnDiamond), it has the half of menu. Right, let us do 
the same with java 1.6.x. After cleaning the .eclipse and workspace 
folders, and starting DawnVanilla, an exception is thrown (see below), 
but the whole menu appears! In addition, if I switch to java 1.7.x after 
the first run, it runs without the exception (of course), and the whole 
menu appears! With other words, if I run DawnVanilla first with java 
1.6.x, and second with java 1.7.x, it starts working. It looks like 
something is cached in .eclipse and workspace folders related to java 
1.6.x, and when it is done, java 1.7.x can be used. Note that 
DawnDiamond build does not require this double time start trick, in 
addition it works either with java 1.6.x or java 1.7.x. One could say, 
it is because java 1.7.x is included in DawnDiamond. Well, dViewer also 
contains java 1.7.x, and does not work as DawnDiamond. I really would 
like to know how we could produce similar build to DawnDiamond which 
works with at least one java version, either 1.6.x or 1.7.x.
While we are at it, I would like to mention a problem for presenting how 
much the builds differ. This problem appeared in DawnVanilla (past 
tense, because I fixed it), and does not appear in DawnDiamond. Shortly, 
the runlevel of uk.ac.diamond.scisoft is set to 1, which means it starts 
before the workspace, and stops after the workspace. Despite of this, in 
its activator it called super.stop(context), which tried to save values 
in the workspace (yes, in the workspace which is stopped already). This 
obvious error caused an exception in DawnVanilla, but nothing happened 
in DawnDiamond. I removed the calling of super.start(context) and 
super.stop(context), and since then there is no exception. Besides, in 
that plugin there is nothing to save.

Any question or comment is welcome.

Cheers,
Gábor

org.osgi.framework.BundleException: The bundle 
"uk.ac.diamond.scisoft_1.1.0.v20131021-1103 [394]" could not be 
resolved. Reason: Missing Constraint: Require-Bundle: org.python.pydev; 
bundle-version="[3.0.0,3.1.0)"
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332)
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316)
         at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:300)
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:292)
         at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:325)
         at 
org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
         at 
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
         at 
org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
         at 
org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:48)
         at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
         at java.security.AccessController.doPrivileged(Native Method)
         at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
         at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
         at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
         at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
         at 
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
         at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
         at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
         at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
         at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
         at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
         at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
         at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
         at 
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)