packaging questions

[bzeiss]

is it intentional that gwt designer is not packaged with the windowbuilder pro zip? i basically prefer downloading the zips rather than executing an installer. having said that, i wonder why windowbuilder doesn't make use of the update site functionality. that would certainly make updating the integration builds a lot easier.

[Eric Clayberg]

is it intentional that gwt designer is not packaged with the windowbuilder pro zip?

For now, yes. We don't want to force the extra GWT stuff on existing WB customers unless they want it. The GWT Designer installer includes all of WB, so you don't need to install both.

i basically prefer downloading the zips rather than executing an installer.

OK. I added a link to the ZIP builds containg GWT Designer to the main WB download page. The latest ZIP build can be downloaded here.

having said that, i wonder why windowbuilder doesn't make use of the update site functionality. that would certainly make updating the integration builds a lot easier.

We are considering it, but update sites become complex when you have multiple Eclipse versions to support and a continuous build process. It might be annoying if the update manager announced a new build was available several times a day.

[bzeiss]

Thanks a lot for the ZIP!

About the update site complexity, i don't know. I have automated the build process for the open source project where i am involved (http://www.trex.informatik.uni-goettingen.de) for release and nightly builds (including installer etc.) and i thought the time investment was worth it. Considering Eclipse bugging about updates, i believe that the user should be able to choose, e.g. between weekly integration builds or daily nightly builds. Of course, when critical bugs are found, these regular builds can always be executed by hand to allow earlier updates. At least that is how i would do if i had more than the two or three existing users for my project

However, I am happy with the ZIP for now! Thanks!

[Eric Clayberg]

We do plan to create update sites in the future, but it does get messy when you need to support multiple versions of Eclipse that all have slightly different update site requirement in combination with different build streams and product configurations.

For our WindowBuilder product family, for example, we could potentially need 48 different update site combinations: 4 major product configurations (WindowBuilder, Swing Designer, SWT Designer & GWT Designer) x 4 Eclipse versions (3.0, 3.1, 3.2 & 3.3) x 3 build streams (release, integration & continuous).

[bzeiss]

who uses 3.0 and 3.1 anyway ok. point taken.

[Eric Clayberg]

who uses 3.0 and 3.1 anyway

Based on our product activation records for the last month (for all of our products), I would say about half of our users are using an Eclipse version that predates Eclipse 3.2.

Most major corporate users of Eclipse-based IDEs still use Eclipse 2.1 (WSAD 5.1) or Eclipse 3.0 (RAD 6.0). IBM's upcoming RAD 7.0 will be based on Eclipse 3.2, but typical adoption rates are 12-18 months.

Scary, but true.