Does anyone know when the menu cleaning was done? Maybe my DawnDiamond
version it too old (1.5 month!), and that is why it starts with 8 menu
entries. Still interesting that with java 1.6.x there are still 8 menu
entries.
Gábor
30/10/2013 14:02 keltezéssel, Gábor Náray írta:
> Interesting question if I need the menus. However the problem is that
> DawnVanilla produces 4 menu entries with java 1.7.x, and 8 with java
> 1.6.x, in addition without any error message. I understand java 1.7.x
> should be used, but then how DawnDiamond can start with 8 menu
> entries? Quite confusing.
>
> Gábor
>
> 30/10/2013 13:49 keltezéssel, Jacob Filik írta:
>> Missing menus is not a bug. Unused menus were removed from the
>> databrowsing perspective (using perspective extensions extension
>> point) only as part of trying to clean up the ui.
>>
>> Do you need these menus? They have been missing a while...
>>
>> Jake
>>
>>
>>
>> -------- Original message --------
>> From: [log in to unmask]
>> Date: 30/10/2013 13:23 (GMT+01:00)
>> To: [log in to unmask]
>> Subject: Re: [DAWN-DEV] Question about a critical bug in DawnVanilla
>>
>>
>> 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
>>
>>
>
|