Windowtester open sourcing

807 views
Skip to first unread message

Keerti Parthasarathy

unread,
Mar 7, 2012, 1:07:32 PM3/7/12
to windowtester-pro
For all those who have waited for so long, we are pleased to announce the open sourcing release of WindowTester. 


The project site for windowtester is 

Eric Clayberg

unread,
Mar 7, 2012, 1:09:49 PM3/7/12
to windowte...@googlegroups.com
Great job, Keerti! Thank you for all of your hard work in making this happen :-)

viktara

unread,
Mar 8, 2012, 4:34:12 AM3/8/12
to windowtester-pro
Brillant news - thanks!

ronnie

unread,
Mar 9, 2012, 3:46:59 AM3/9/12
to windowtester-pro
Thanks Keerti,

How is the further development for WT planned, will it be community
driven or on individual basis?

--Saurabh

Eric Clayberg

unread,
Mar 9, 2012, 8:31:15 AM3/9/12
to windowte...@googlegroups.com
Both. The primary reason to open source WT is to get community help.

Now that the source is available, we will be very happy to look at patches and add new committers to the project.

Wes

unread,
Mar 9, 2012, 2:09:04 PM3/9/12
to windowtester-pro
This is long-awaited great news!

I do appreciate that Google/Instantiations folks built it and spent
the time, money, effort, and political capital to make it viable on
its own. Thanks.

That said, I didn't see any tag/branch for the last release, open/
immigration issues or maintenance tasks, thumbnail plans for the next
release, etc. With the eclipse 3.x line ending and the probably
significant work required for 4.x, I'm guessing WT efforts would be
divided. Others probably want the challenge of making it work for
4.x, but we're invested/interested in 3.x, so I'd like to aim for bug-
fix release in the June time frame.

Wes

Eric Clayberg

unread,
Mar 9, 2012, 2:15:54 PM3/9/12
to windowte...@googlegroups.com
All of the WT code needed to be cleaned up and proper header comments applied. As a result, all of the code that was released is actually newer than what was in the most recent release. What is there should pretty closely match the latest release plus any minor bug fixes that might have been applied since then. As far as plans are concerned, this is a clean slate and we are open to whatever the community wants to do with it. If anyone is interested in becoming a committer and really pushing on the code, just let us know. Eclipse 3x/4x compatibility is pretty good, so I hope WT will continue to work pretty well in the 4x world. New, 4x-only constructs will likely need some work.

Wes

unread,
Mar 12, 2012, 1:15:52 PM3/12/12
to windowtester-pro
Hi Keerti,

Could you provide instructions on building the code with a fresh
Eclipse (on the wiki)?

Or provide the .target files or the ant taskdefs read_feature,
init_properties, read_build (and others?)? There's also a reference
to a project com.instantiations.pde_build_shared, and enticing version-
specific code prefixed with comments like /* $if eclipse.version >=
3.6 */. Explain?

It's possible now to cobble together the target and export some
features (using guesswork that's not wiki-worthy). Best would be some
build process that ran tests so contributors could verify their
patches. Whether Tycho, Ant, or PDE, to start with I'm just looking
for something everyone can do in the relative safety of their home :)

Thanks,
Wes

Keerti Parthasarathy

unread,
Mar 15, 2012, 11:44:38 AM3/15/12
to windowte...@googlegroups.com
Unfortunately, the scripts that we use to build windowtester are dependent on Google internal build infrastructure, so we cannot make it available to the public.

That said, if anyone can put together an ant script to build windowtester, that would be great. 

The version specific prefixed code was used by the build script to do some preprocessing, since it was building for  different versions of eclipse. 

Thanks,
--
Keerti

Fred G

unread,
Mar 20, 2012, 9:06:47 AM3/20/12
to windowte...@googlegroups.com
Keerti & Eric,

Thank you very much for finally open sourcing this great piece of software.

I have a few question regarding the future development of windowtester:
1. It seems there hasn't been much active development in the last months apart from a few bugfixes and the (certainly time-consuming) process of open-sourcing. Are there still resources assigned to this project that will actively drive the development? Or just someone supervising the project, maybe reviewing patches and releasing? Or will this project be eventually handed over entirely to the community?
2. I haven't dealt with code for different version of Eclipse in a single workspace yet. Without the build scripts, that use the prefixed code, I guess it would be easier to put the code in to different SVN branches though. Would you agree?
3. Will all future bugs, enhancements, etc. be monitored at https://code.google.com/p/windowtester/issues/list?
4. What's the process for submitting a patch?
5. I'd like to become a committer. What steps are required? Are there any style guides, formatting templates that should be adhered?

Regards,

Fred

Eric Clayberg

unread,
Mar 20, 2012, 10:11:24 AM3/20/12
to windowte...@googlegroups.com
Fred,

Thank you very much for finally open sourcing this great piece of software.

You're welcome. Keerti deserves all the credit for doing the work to make it happen. I also applaud Google's willingness to allow the code to be open sourced (this being the second major piece of former Instantiations IP that we have open sourced - the first being WindowBuilder).
 
I have a few question regarding the future development of windowtester:
1. It seems there hasn't been much active development in the last months apart from a few bugfixes and the (certainly time-consuming) process of open-sourcing. Are there still resources assigned to this project that will actively drive the development? Or just someone supervising the project, maybe reviewing patches and releasing? Or will this project be eventually handed over entirely to the community?

WindowTester is what we would call a 20% project for one person (most of that time consumed by the open source process in recent months). Given Google's development priorities for our team (e.g., not on WindowTester), our active involvement wil be focused on bug fixes, reviewing patches, and releasing updates. Ideally, we woud like to see interested members of the community step up and carry it forward. To that end, we are very interested in bringing on new committers.
 
2. I haven't dealt with code for different version of Eclipse in a single workspace yet. Without the build scripts, that use the prefixed code, I guess it would be easier to put the code in to different SVN branches though. Would you agree?

Possibly. We can also look at releasing the preprocessor code that we use for generating the Eclipse-specific versions. That could be called from a simple ANT script used to build each version. The default version of the code (no preprocessing required) should reflect the current version of Eclipse.
 
3. Will all future bugs, enhancements, etc. be monitored at https://code.google.com/p/windowtester/issues/list?

Yes. We would like all bugs and enhancement tracked out in the open in the public issue tracker.
 
4. What's the process for submitting a patch?

For now, I would suggest creating a new issue in the issue tracker (bug or enhancement) and attaching the patch there.
 
5. I'd like to become a committer. What steps are required?

How about these:
  • Express genuine interest
  • Follow through on that and submit 3(?) patches (we're open to what this number should be)
  • Request to become a committer
  • Existing committers vote to accept
Are there any style guides, formatting templates that should be adhered?

Not really. Any reasonable style is fine with us. You can always use the existing code as an implied (but nit required) style guide. We rather focus on the content of the patches than the code style used. If you are serious about becoming a committer and start contributing code, we will be happy with whatever style you are comfortable with.

-Eric

Fred G

unread,
Mar 20, 2012, 11:15:07 AM3/20/12
to windowte...@googlegroups.com
Eric,

Thanks for the quick reply and the reasonable (and expected) explanation why the development was rather slow.

It's too bad that Window Tester does not have a higher priority, but at the same time I'm grateful that Google did the right thing and allowed the open sourcing.

The preprocessor code would be very much appreciated. So far I have to comment in/out all version specific code that is not compatible with my current development environment.

We successfully use window tester in our production environment to test our Eclipse-based application. That's why I have a genuine interest to contribute to the further development as much as my limited spare time allows it.

I'll submit some patches in the next days.

Regards,

Fred

Eric Clayberg

unread,
Mar 21, 2012, 7:34:57 PM3/21/12
to windowte...@googlegroups.com
Fred,

Thanks for the quick reply and the reasonable (and expected) explanation why the development was rather slow.

The ex-Instantiations folks who created WT are in demand internally at Google due to their Eclipse expertise. Most of us are now working on the Dart Editor project. That said, we still (personally) care about the products that came with us to Google. That is why they were all made free (Google doesn't sell stuff like this so the choice was shelve them or set them free). Work on WT is limited to how much free time we have. That is also why we have worked long and hard to open source it so that other interested folks can work on it.

It's too bad that Window Tester does not have a higher priority, but at the same time I'm grateful that Google did the right thing and allowed the open sourcing.

Google just isn't in the business of delivering general purpose Eclipse tools. All of our Eclipse tools are there to serve one of our major app development systems (ADT for Android, GPE for GWT, etc.). Fortunately, Google allows us to "do the right thing" or the "non-evil" thing and make the code freely available to anyone who can make use of it.

The preprocessor code would be very much appreciated.

We should be able to release that as well fairly soon...maybe even the build code if we can sanitize it and decouple it from the Google build environment. Having someone create a simple ANT script that invokes the preprocessor and then creates the plugins would be better though.
 
So far I have to comment in/out all version specific code that is not compatible with my current development environment.

We'll work on solving that problem for you.

We successfully use window tester in our production environment to test our Eclipse-based application. That's why I have a genuine interest to contribute to the further development as much as my limited spare time allows it.

We are very happy that you are interested in helping.
 
I'll submit some patches in the next days.

Great. Thanks!

-Eric 

David Cummings

unread,
Apr 2, 2012, 10:23:53 AM4/2/12
to windowte...@googlegroups.com
Nice meeting you gentlemen at EclipseCon last week. Glad to hear that you are hoping to release the preprocessor code and perhaps that build code. We use WindowTester for a good portion of our test automation and there are a few blocking bugs that I'd like to contribute to get us going again.

You asked me to follow up on the message board, so here it goes:
* You mentioned that the current source is the one that build the 3.7 update site, but I don't see any preprocessor code or a ProgramArgumentBuilder37 in the source. Should this source in fact build against 3.7?
* There seems to be some dependencies that are missing, even after I've stripped out the preprocessor code. Specifically the plug-in "com.windowtester.swt.platform.ext" isn't in the repo, There are also a few errors relating to missing classes in com.windowtester.swt.runtime.legacy
* I'm trying to build on OSX and there are a few issues:
** The platform specific plug-ins seem to expect a 3.5.0 SWT jar to exist in the "delta-pack" directory under my ECLIPSE_HOME. Why does it depend on a particular version of the SWT jar and why doesn't it grab it from the PDE target?
** There are few problems related to the MacExtensions class and it's availability to other plug-ins. Adding in the proper dependencies leads to cyclical dependency issues

Thanks,
David

Lars Gjesse

unread,
Apr 22, 2012, 4:18:29 PM4/22/12
to windowte...@googlegroups.com
Eric,

Thank you for sharing with us the considerations that led to open sourcing WT.

But now that you and other ex-Instantiation employees are still working with Eclipse development, I was curious to know if you will be using WT yourselves for testing the Dart Editor.

Regards,

Lars

Eric Clayberg

unread,
Apr 30, 2012, 8:38:58 AM4/30/12
to windowte...@googlegroups.com
That is certainly possible. The current Dart Editor team has both WT and SWTBot experience, so we will likely use one or both of those. We're agnostic as to which one we will use and both will do the job.

David Cummings

unread,
May 15, 2012, 11:18:28 AM5/15/12
to windowte...@googlegroups.com
Any chance someone will have time to follow up on these q's?

Keerti Parthasarathy

unread,
May 15, 2012, 12:12:23 PM5/15/12
to windowte...@googlegroups.com
David,

Sorry for taking so long to reply. Here goes

>* You mentioned that the current source is the one that build the 3.7 update site, but I don't see any preprocessor code or a ProgramArgumentBuilder37 in the source. Should this >source in fact build against 3.7?

Right now it is being built against 3.7, but we so not have a
ProgramArgumentBuilder37, which we should have, but never got around
to it.

>* There seems to be some dependencies that are missing, even after I've stripped out the preprocessor code. Specifically the plug-in "com.windowtester.swt.platform.ext" isn't in >the repo, There are also a few errors relating to missing classes in com.windowtester.swt.runtime.legacy

The "com.windowtester.swt.platform.ext" is indeed missing, and you can
ignore the errors due to that. The lecacy plugin is as the name
implies, legacy and it is not complete code.

>* I'm trying to build on OSX and there are a few issues:
>** The platform specific plug-ins seem to expect a 3.5.0 SWT jar to exist in the "delta-pack" directory under my ECLIPSE_HOME. Why does it depend on a particular version of >the SWT jar and why doesn't it grab it from the PDE target?

Look like a version number might have been specified when the
dependency was added. Will take a look.

>* There are few problems related to the MacExtensions class and it's availability to other plug-ins. Adding in the proper dependencies leads to cyclical dependency issues

What are the errors you are seeing in the macextensions?
--
Keerti

cthulhu314

unread,
Jul 11, 2012, 5:19:48 AM7/11/12
to windowte...@googlegroups.com
Hi Keerti,

is there any progress about making Windowtester builds work outside of Google? We are evaluating GUI testing tools for Eclipse and Windowtester is our favourite so far, but we use a slider in our application and the current beta for Eclipse 3.7 doesn't support this widget (see the slider issue thread in this group). We would like to look into it, but without a working build system we cannot do anything.

Maybe you could just create different branches in the repository for the different Eclipse versions? This way the standard eclipse build schemes could be used...

Karsten

Martin Moore

unread,
Jul 11, 2012, 8:23:58 AM7/11/12
to windowte...@googlegroups.com
Hi Cthulu,

See the following from Keerti:

...Our build engineer has moved on to a different project, so am trying to get some time from him for a new build with all the fixes. Hopefully it will be soon.

I'd imagine this is related to the whole build system being non existent.

Also: Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Cheers,
M

Keerti Parthasarathy

unread,
Jul 11, 2012, 11:40:07 AM7/11/12
to windowte...@googlegroups.com
We do have plans to opensource the build structure too, but not sure when this will happen. In the meantime will see what can be done to make it easier to set up a build for WindowTester.
--
Keerti

Max

unread,
Dec 10, 2012, 7:28:31 AM12/10/12
to windowte...@googlegroups.com
Hi Keerti,

would it make sense if we'd use issues and patches to get the necessary infrastructure into the repository?
As I see it, everything developers would need in order to build a Windowtester-p2-update-site with 'mvn clean install' can be managed with Subversion.
- pom.xml in each project plus a parent-pom in an extra project
- some changes to build.properties, etc.
- pre-compiler instructions / legacy code => branches

With that in place, automizing the build and creating releasees periodically would also be quite simple.

It seems some people already have most of these changes in their workspace and would merely need to commit them.
Any thoughts on that?

Best Regards
Max

Tony Clarke

unread,
Mar 13, 2013, 8:14:46 AM3/13/13
to windowte...@googlegroups.com
It's 2013. Any updates on how the build has been open sourced?

John O Rourke

unread,
Feb 14, 2014, 8:52:21 AM2/14/14
to windowte...@googlegroups.com
Any plans to hand this project over to the Eclipse community, like the Window Builder project?

Eric Clayberg

unread,
Feb 14, 2014, 9:06:31 AM2/14/14
to windowte...@googlegroups.com
We would be supportive of anyone (Fred, for example) who wanted to do that, but doing so is not easy. Getting a project accepted by Eclipse.org takes a lot of work, and we spent several months prepping WindowBuilder. Projects go through a lengthy IP vetting process and must include a team of committers willing to work on the project and follow the Eclpse.org process. 


--
You received this message because you are subscribed to the Google Groups "windowtester-pro" group.
To unsubscribe from this group and stop receiving emails from it, send an email to windowtester-p...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply all
Reply to author
Forward
0 new messages