Please remember - two set of eyeballs on changes before they go into code frozen branch
by Max Rydahl Andersen
Hey,
Just a reminder that we are in code frozen state for JBoss Tools and
Developer Studio.
That means *any* change, no matter if in code, docs, releng scripts,
etc. should at least have
someone else review it *before* it goes into the 4.3/9.0 branches.
It does slow things down, but
we've found more in these reviews historically than I care to think what
we missed - plus it helps
spread the knowledge of what is going in ;)
Also, having *tests* included for the changes is crucial and very
helpful in getting it reviewed faster.
We got a good chunk on vacation but this week Alexey, Denis, Fred and I
are still around so do please
ping on #jbosstools if you are missing a set of eyes.
Thanks,
/max
http://about.me/maxandersen
10 years, 12 months
foundation tests
by Rob Stryker
Hi All:
I'm a little curious why there's a need for the number of test plugins
in foundation. Currently I see
org.jboss.tools.foundation.checkup.test
org.jboss.tools.foundation.core.test
org.jboss.tools.foundation.help.test
However, checkup and help are both 1 or 2 classes in the entire plugin,
and neither one of them seem likely to require additional tests. Why
were these tests added to their own plugin?
I'm asking because I'd like to add some new UI tests, and I think adding
a 4th plugin seems a bit ridiculous. Wouldn't it make more sense to just
have a foundation.core.test and a foundation.ui.test, and move the
checkup and help tests into whichever makes more sense?
- Rob
10 years, 12 months
Re: [jbosstools-dev] Fwd: Quick SWT Question
by Ian Stewart-Binks
Holy cow. Thanks for the help, all. Zimbra's presented me with quite the sea of... quotation-al soup.
Not sure if I'm doing the jbosstools-dev mailing list right. Here goes...:
> Date: Wed, 15 Jul 2015 16:19:56 +0100
> From: phantomjinx <p.g.richardson(a)phantomjinx.co.uk>
> In addition to Display.asyncExec, you make want to put your code inside a runnable, launched from
> its own thread.
> My reasoning:
> The workbench can be started after some plugins have already been activated as such
> getWorkbench().getActiveWorkbenchWindow() can be null even on the UI thread. Consequently, I find
> it prudent to create a polling thread that listens on getWorkbench().isStarting().
Thanks for your suggestion, Paul.
At what point am I guaranteed that there is an active workbench window?
Is it necessary to poll the workbench to see when it's active? Is it likely that plugins crash otherwise?
> Returns true then delay
> Returns false then the workbench window should exist as well as the Display thread and so
> Display.asyncExec(addSelectionServiceRunnable) should be good to go.
> Once control has been passed to the Display thread, the original polling thread will finish and
> disappear.
> HTH
> PGR
> From: Denis Golovin <dgolovin(a)exadel.com>
Thanks for your response, Denis.
> Ian,
> Bundle.start() is always none UI thread.
I'm not entirely certain that Bundle is an ancestor of the class I'm referring to.
The listener appears to be registered successfully when the plugin is run,
and it only has this problem in the context of SWTBot testing.
> If the tool is targeting Eclipse 4
> and up, you can try to use injection see details here
> https://wiki.eclipse.org/Eclipse4/RCP/EAS/Workbench_Services.
Thanks for the link. The plugin also targets Eclipse 3 platforms, but I'll take a look at this nevertheless
> I can be more
> specific if you could share your source code.
This is the PR that adds in the listener, and everything listener like:
https://github.com/eclipse/buildship/pull/120
> Denis
> From: "Max Rydahl Andersen" <manderse(a)redhat.com>
Thanks for your response, Max.
> I think you need to look *when* you actually need the selection listener
> registered.
This is indeed something I'm doing right now. However, the UiPlugin seems to have a pattern of
registering/unregistering listeners/services on start/stop. I'm hesitant to break that pattern.
> Normally it is not something to do at startup, but more when your gfx
> part (editor/view etc.) gets created you need to start to listen.
I'll need to do a bit more reading on this one in order to see if it's a feasible solution.
The selection listener seems to be fairly general. I'm still taking the time to understand its purpose
and what the best solution is. For reference, this shows the earlier state of the code: https://github.com/eclipse/buildship/pull/120/files
> /max
From: Alexey Kazakov <alkazako(a)redhat.com>
Subject: Re: [jbosstools-dev] Quick SWT Question
To: jbosstools-dev(a)lists.jboss.org
Message-ID: <55A6948C.1000906(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
> Agree with Max. But if you really need something general to listen to
> everything you can use the early start up mechanism (see
> org.eclipse.ui.IStartup). Your code will be invoked when the workbench
> is initialized.
> For example we use it in our usage to register a wizard listener to be
> able to track all wizards in Eclipse.
I'm looking at this solution now. Is there any chance that the 'BundleActivator.stop()' method (the method that unregisters the listener, if it hasn't already been unregistered) could be invoked before the 'earlyStartup' method?
11 years
We are the only licensed distributor of many world-famous medications! Shop smart!
by Canadian-Pills
Cites no tooth, there downhill with s. Refreshing read when im even
their cards while another.
Me
ds
8f
or
6M
en
Vi
Ci
Ci
Le
Pr
ag
al
al
vi
op
ra
is
is
tr
ec
S
a
ia
of
t
Ta
bs
$0
$1
$2
$2
$0
.9
.6
.5
.5
.4
9
5
0
0
5
Me
ds
6f
or
2W
om
en
Ac
Cl
De
Fe
Fe
om
om
fl
ma
ma
pl
id
uc
le
le
ia
an
C
V
ia
ia
li
gr
s
a
$1
$0
$1
$1
$0
.7
.4
.2
.1
.7
5
5
5
1
2
Vi
On
10
An sa
ly
0%
on ,M
r
A
ym as
el
ut
ou te
ia
he
s rc
bl
nt
de ar
e
ic
li d,
su
M
ve Ec
pp
ed
ry he
li
s
ck
er
s
N
S
F
2 o
pe
as
4/ pr
ci
t
7 es
al
wo
cu cr
i
rl
st ip
nt
dw
om ti
er
id
er on
ne
e
s r
t
sh
up eq
pr
ip
po ui
ic
pi
rt re
es
ng
d
>> Enter Here
11 years
Fwd: Quick SWT Question
by Fred Bricon
CC-ing to jbosstools-dev for more exposure
> Début du message réexpédié :
>
> De: Ian Stewart-Binks <istewart(a)redhat.com>
> Objet: Quick SWT Question
> Date: 15 juillet 2015 09:05:06 UTC−4
> À: Denis Golovin <degolovi(a)redhat.com>
> Cc: Fred Bricon <fbricon(a)redhat.com>
>
> Hi Denis,
>
> I'm the JBoss Tools intern here at Red Hat, working on an Eclipse plugin called Buildship[1].
>
> I have an SWT related question, and my mentor, Fred Bricon, has suggested that I ask it to you.
>
> The plugin I'm working with makes a call to getWorkbench().getActiveWorkbenchWindow() in the plugin's Activator's .start() method.
> This call returns null when it is not run on the UI thread, so the code is assuming that the .start() method will always
> be run on the UI thread. The AbstractUIPlugin[2] states that the deprecated method startup(), which start() is meant to replace cannot assume that it is run on the UI thread. This may be a bit pedantic: the specification for start() doesn't mention anything about the UI thread- is it still the case that we can't assume the start() method is run on the UI thread?
>
> If it is the case that the start method can't assume that it's run on the UI thread, I will need to change some of the code to ensure that this assumption is not made.
>
> The offending line attempts to register a selection listener. Here it is:
> ((ISelectionService) getWorkbench().getActiveWorkbenchWindow().getService(ISelectionService.class)).addSelectionListener(this.contextActivatingSelectionListener);
>
> Do you know of any other ways to register this listener?
>
> Your help is greatly appreciated.
>
> Thank you,
> Ian
>
> [1] - https://github.com/eclipse/buildship/
> [2] - http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc....
11 years
