I was able to reproduce the "missing menu" part (including the Java 6 priming) with DawnDiamond (dating back to 2013-10-18, pre the PyDev 3.0 change) - the problem also happens in builds since then. I will go through old builds and try and find out when it started happening.

It's quite surprising that this wasn't picked up in the Squish tests.

The other problem, Missing Constraint: Require-Bundle: org.python.pydev, is either a straight build error, or you are using an old workspace. Remember that we updated PyDev and changed the dependencies, so build with a completely fresh materialize (or follow my instructions to the list on 21/10/2013), and use a new (or -clean'd) workspace.

> -----Original Message-----
> From: DAWN Science Developers [mailto:[log in to unmask]] On Behalf Of Gábor Náray
> Sent: 30 October 2013 10:33
> To: [log in to unmask]
> Subject: [DAWN-DEV] Question about a critical bug in DawnVanilla
> 
> 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.j
> ava: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(SimpleConfig
> uratorImpl.java:129)
>          at
> org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfig
> uratorImpl.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)

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom