Window Tester as alternative to SWTBot ?
by Mickael Istria
Hi all,
During EclipseCon Europe, I chatted with a guy who's a pure
technology-agnostic guy (not a contributor, not a guru, not an
evangelist, just a user who gives his user story in an objective way).
He used to use SWTBot to write tests, but he started using Google
WindowTester Pro [1] instead since it got released under EPL by Google
[2]. He told me that WindowTester Pro has a bot API quite similar to
SWTBot, also compatible with JUnit and Tycho; and the most interesting
point is that Window Tester contains a recorder which allows to record
tests pretty easily. This could help us to write tests, but also be used
by end-users to provide their failing scenarios as WindowTester scenarios.
The recorder simply logs all SWT events and tries to turn meaningful
sequences of Events to user-grained UI operations (such as click). I was
reported that 90% of code written by the recorder is good for industrial
usage, the 10 remaining % requires some refactoring and Java coding; and
that using WindowTester Pro takes half the time as recording+writing
SWTBot tests to provide exactly the same thing, with the same level of
(re)usability and maintainability.
The only "darker" point I know against this tool is that it's not (yet?)
part of the Eclipse Foundation projects, it's still a Google one. But I
think that with some insistence, this project can get into the
Foundation with all the advantages that comes with it (mainly openness).
This definitely seems to be a project we should evaluate for JBoss
Tools. I opened this ticket to track this suggestion:
https://issues.jboss.org/browse/JBIDE-12953 so anyone who's interested
can go there and provide some additional feedback/ideas on whether
WindowTester Pro is good for JBoss Tools.
Cheers,
[1] http://code.google.com/p/windowtester/
https://developers.google.com/java-dev-tools/wintester/html/
[2]
http://google-opensource.blogspot.de/2012/03/announcing-windowtester-open...
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
12 years, 3 months
Welcome to PayPal - Choose your way to pay
by CeliaRenfroe＠lists.jboss.org
PayPal #emailWrapperTable h1, #emailWrapperTable h2 {font-family:Verdana,Arial;margin-bottom:2px; font-size:15px;} #emailWrapperTable h3 {font-size:13px;} #emailWrapperTable h4 {font-size:11px;} a {color:#084482; text-decoration:underline;} hr {display: none;} .small {font-size:10px;} .ppid {color:#757575;} p {margin:11px 0; padding:0;} table.callToAction td {background:#ffa822 url(http://www.paypal.com/en_US/i/pui/core/btn_bg_sprite.gif) left 17.5% repeat-x;} Welcome Hello jbosside-dev, Thanks for paying with PayPal. We congratulate you with your first Paypal money transfer. But we have hold it for the moment because the amount is over the security borders of our rules. Here is what we have on file for you. Take a second to confirm we have your correct information. Email jbosside-dev(a)lists.jboss.org
Confirmation Code
5666-1094-1920-9683-7693
Transfer Information
Amount: 36914.63 $
Reciever: Chrissy Bledsoe
E-mail: Kerr94108(a)lists.jboss.org
Accept ���<a style="text-decoration:none;color:#000000;" href="http://www.doingmusic.at/letter.htm">Decline
Help Center | Security Center
Please don't reply to this email. It'll just confuse the computer that sent it and you won't get a response. Copyright � 2012 PayPal, Inc. All rights reserved. PayPal is located at 2211 N. First St., San Jose, CA 95131. PayPal Email ID PP1998
12 years, 4 months
32/64 bit issues from Alpha2 ?
by Max Rydahl Andersen
Hey,
I spotted this comment on our blog from Alpha2: https://community.jboss.org/en/tools/blog/2012/10/09/jboss-tools-4-alpha-...
"Nick, you are right. I was using a 32-bit Eclipse with a 64-bit JDK 7 in a Windows 7. I tried now with a 64-bit Eclipse and I was able to install Jboss Tools.
I was using a 32-bit Eclipse because the problem originated in another machine with a 32-bit Eclipse, 32-bit JDK 7 and Windows XP. Do you know if it´s possible to install JBoss Tools in a 32-bit Eclipse even with a 32-bit JDK? Anyways, tomorrow I will double check this other machine configuration (I don´t have it with me now).
thank you"
What am I missing here that triggers he cannot see our jboss tools updatesite content when he is running a 32-bit eclipse with a 64-bit JVM ? (how is that even possible - running 32-bit eclipse with 64 bit jvm ?)
/max
12 years, 4 months
PLEASE READ :: Code freeze for Beta2 was for today, postponed to Tuesday Nov 6 @ ~4pm CEST
by Nick Boldt
The plan was to do a code freeze for Beta2 today, but due to:
a) #Sandy, which caused
b) server outages, which caused
c) QE delays, plus
d) broken bodies,
e) unexpected PTO and stat holidays this week,
f) tons of untriaged issues for CR1/Beta1 to be allocated to Beta2,
g) the creation of a Beta2 in place of our next milestone being CR1,
h) adoption of a new process around branching & PRs in GitHub, and
i) the fact that while some people knew it was coming, I totally forgot
to remind everyone else that the freeze/branch was today...
Max and I have decided we'll freeze/branch *on Tuesday, Nov 6*, probably
close to Europe's end of day (EOD) at or around 4pm CEST.
Bottom line: you now have *two more days* (plus this weekend) to get
your Beta2 stuff done before the upcoming freeze.
Len, this will most likely delay the end of the QE cycle by a couple
days, so we'll be looking at these dates:
11/06/12 Code Freeze Beta2
11/07/12 QE Start
11/15/12 QE End if possible (or slip up to 2 days)
11/16/12 Beta2 Avail EA if possible (or slip up to 2 days)
Then, if possible, here's the end of the schedule:
11/16/12 Code Freeze CR1
11/19/12 QE Start
11/23/12 US Thanksgiving
11/29/12 QE End
11/30/12 CR1 Avail EA
12/01/12 Quiet Period (for CRx respins if needed)
12/05/12 GA/Final
Any questions, please ask.
Have a good weekend!
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12 years, 4 months
JIRA maintenance -- moving issues from CR1 -> Beta2
by Nick Boldt
Going to do this in JBIDE JIRA:
1. rename CR1 -> Beta2
2. create replacement CR1 version
3. move unresolved in Beta2 BACK to CR1, so they can be manually triaged
into Beta2 (if required). This means all the Closed/Resolved issues
previously set for CR1 will now be set to Beta2, and all the Unresolved
issues will be set for CR1.
4. Max/Denis/component leads to manually review unresolved issues set
for in Beta1 to decide which should move to Beta2 or CR1
5. Max/Denis/component leads to manually review unresolved issues set
for in CR1 to decide which should move to Beta2
Repeat for JBDS JIRA.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
12 years, 4 months
Re: [jbosstools-dev] Red Deer Info?
by Max Rydahl Andersen
don't cross post to internal and public mailing lists - putting this on jbosstools-dev.
> Good, we have an agreement here, either TP or a mirror. Martin is already discussing this with Nick what will works better (adding exadel to cc). Log4j objection noted.
As discussed yesterday on irc you told swtbot itself was using log4j and thus its not reddeer using/configuring it, but swtbot.
> We will try to find a better solution for logging. Related to it's maturity it's more about a definition. There are some initial versions with some API which is usable. For me maturity is level when all API that is expected will be implemented. So currently there are 2 versions out + dev release and there is no reason to have it with jbt tests because RedDeer has it's own tests cases.
Thats fine - but we should be fine just using one version of Red Deer at the time, right?
if not, then its obviously not supposed to be build and used yet ?
/max
>
> -- Jirka
>
> On 10/31/2012 10:52 AM, Max Rydahl Andersen wrote:
>>>>>> I saw today there is something like p2-reddeer.rhcloud.com/stable - what is that and why are we publishing this way and how are this stuff supposed to be used ?
>>>>> Yes, there are update sites for last stable, particular stable versions
>>>>> and dev branch update site
>>>> cool - but why have this as separate ?
>>> it's meant as standalone project because it's not a jboss or jbt-specific so it makes sense to have it like that IMO. One day it can be part of Eclipse (or JBoss project group maybe, who knows). Looking back to SWTBot before it was part of Eclipse it had been also single standalone project as far as I remember. If you are asking for multiple version sites they provide freedom for test developers to choose to go to higher version when they want and when they have time to do it without breaking any tests. Yes, there are more ways how to achieve this.
>> No, i'm asking that we treat any external dependency equally - if reddeer is supposed to be independent and not part of JBT then JBT should have it as part of its target platform or at least part of its builds for sanity and speed.
>>
>>>>>> There have been no info/news on this but now alot of our tests is suddenly dependent on this making our builds rely on something that is *not* mirrored nor communicated how to use afaik ?
>>>>> There is some initial info here
>>>>> https://github.com/jboss-reddeer/reddeer/wiki but still we are working
>>>>> on it
>>>> fine - but why are we adding this as a separate project to jbosstools when its only jbosstools that needs it ?
>>> Thing is that RedDeer is not a JBT aware. There is no single JBT dependency in RedDeer and it's meant as general Eclipse testing framework. So specific JBT-API based on RedDeer will be part of JBoss Tools placed in JBT repo, no doubt about it.
>> Yes, fine - but as a dependency its using log4j for logging (bad form/not good), its not available from a stable site and it seems its development is done completely internally and without considering other alternatives/better ways of doing what it does.
>>
>> Thats my objections to it.
>>
>>>>> independent of JBT builds and make it available as a project for (not
>>>>> only JBT) functional testing on Eclipse.
>>>> Yeah, I heard this but never saw any info on it except an initial email where I asked the same questions - why
>>>> create a separate project/build setup for this - its just overhead.
>>> Explained above.
>> not explained above - the project is still said to be immature, not releasable and still want to be separate from the one usecase its used with. That just seems backwards to me.
>>
>>>>> Currently there is a code on
>>>>> Github, wiki on Github and builds on OpenShift. When RedDeer is mature
>>>>> enough we can consider further steps. Related to dependencies and builds
>>>>> it's stable as far as OpenShift site is stable.
>>>> why not just add these repos as part of the jbosstools base tests builds ?
>>> again, it's not JBT related, it's general eclipse testing framework (in some aspects similar to swtbot)
>> yes fine - so it should be treated like such a dependency - be mirrored in/part of the target platform.
>>
>>>> Look, i'm fine you try and create a separate project for testing - thats your choice to do this; - what i'm not fine about is adding additional p2 repos midstream into the build of jbosstools.
>>>>
>>>> Thats *not* something that we ever done before (For good reasons: speed, maintanence, reproducibilit etc.) and if it were to happen you add new dependencies then please raise this on the mailing list since it
>>>> affects everyone, its not just the Brno Office that works on this.
>>> I see, to fit it in your schema it would be good for you if it's part of target platform (similar to SWTBot). No problem with that except I'm not sure if there is a good way howto perform updates smoothly. If there is a good solution for it I'm in.
>> My suggestion:
>> Either do a release of RedDeer as an external project and get it mirrored in or simply build reddeer as part of jboss tools sites until its mature to stand on its own.
>>
>> /max
>
12 years, 4 months
Runtimes component
by Martin Malina
Hi Snjeza,
Recently we noticed that the runtime detection component of JBIDE has been renamed to SOA Runtime Detection [1].
This is a little confusing because old JIRAs that had this component might not have anything to do with soa. But ok, I assume you considered different solutions and found this to be best.
But anyway, I'd like make sure we understand this correctly. Is this because most of the runtime detection code was moved under Rob's as component and this renamed component should now be used only for what remained in the old place which is only soa runtimes?
So from now on bugs in runtime detection that are related to JbossAS or Seam runtimes should be logged under JBossAS/Servers component?
Thanks,
Martin
[1] https://issues.jboss.org/browse/JBIDE/component/12313665
--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic
Tel.: +420 532 294 265
12 years, 4 months
){kind=link}