Re: Rational Updater -- WDSCI-L

It's important to note that the "Rational folks" are largely the "WebSphere 
Studio" folks.  They moved to the Rational organization about 18 months before 
the name change, and prior to the release of WSAD 5.1.2 and WDSC 5.1.2.

Personally, I think WDSC 6.0 suffers from problems at every level of the 
product:

- Eclipse 3.0 has a bunch of issues, including many memory-related ones.  I see 
from Eclipse's bugzilla that many of these are now resolved.
- RWD and RAD suffer from bloat.  Many of the new features are truly useful 
(like automated code review), but it seems that not enough effort was put into 
getting these things finished, tested, and efficient (automated code review, 
when tasked to review 4-5 basic CRUD web apps, increases the JVM memory usage 
from the normal 300MB to well over 1GB!!).  The JSP editor (which I think is 
the same one that was donated to Eclipse) has similar problems.
- The WDSC bits seem to be pretty solid, but they're not without issues.  My 
previous PC (a Pentium 4 2.6 GHz w/2GB RAM) would completely lock up WDSC *and* 
Windows if an action blocked in the UI thread.  Many RSE features (opening a 
filter that returns a large number of hits, for example) block the UI thread.

I hope the longer-than-usual development cycle on the next release of the 
Rational tooling means that more effort is being spent in getting things right. 
 I'm personally holding out hope that the next generation is based on Eclipse 
3.2.  Many of the improvements in the Java Development Tools (such as exporting 
refactoring information in JAR files) look very useful.

--Robert Dean


-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx on behalf of Joe Pluta
Sent: Sat 3/4/2006 2:12 PM
To: 'Websphere Development Studio Client for iSeries'
Subject: Re: [WDSCI-L] Rational Updater
 
> From: Jon Paris
> 
> I am getting to _really_ hate this abysmal apology for a piece of
> software....
> 
> I am trying to update my WDSC to the RAD 6.0.1 level from a local copy of
> the update files.
> 
> Should be simple ... Just follow the instructions.  Hah!

Jon, don't get down on WDSC because of the delivery mechanism.  Part of the
problem is the lack of communication between the Rational folks and the WDSC
folks.  It's VERY clear to me that the Rational folks want nothing to do
with the iSeries, and unless we in the community make some noise, this sort
of stuff ic going to continue.  To this point, the merger of Rational and
WebSphere Development Studio has been a failure.

Here is an excerpt from an article I wrote back in November.  It seems
things haven't progressed much:

(excerpted from MC Press Online)

Getting Started

Unfortunately, the very first thing we run across is what can best be
explained as a rather shaky alliance between the Rational and WebSphere
product lines. I don't know the genesis of the problem; lots of WebSphere
folks are on the Rational team, and the toolsets both share the same common
Eclipse underpinnings. But the cooperation between the two groups is less
than stellar, and this fact is readily apparent in the most basic of
actions: updating the tool.

Rational Product Updater

In line with the rebranding of everything in sight with the Rational name,
you now update WebSphere Development Studio Client (WDSC) via something
called the Rational Product Updater (RPU). And if you're directly connected
to the Internet, the installation process is said to work flawlessly. You
probably noticed that I'm not giving it my stamp of approval; that's because
the download is about 1.8GB and on a really great day that's about 22 hours
of download on a 192KB DSL line. Even on a full T1, if you've got just 20
workstations, you're talking about an aggregate of some 50 or 60 hours of
bandwidth. I brought this to the attention of the EGL team, and as they
attempted to address my concerns, that's when things got messy.

It started out pretty hopeful: I was instructed to let the updater update
itself. A relatively small (600KB) download would enhance the RPU to be able
to use local files to update the product. This went smoothly. And then
confusion set in.

Never the Twain Shall Meet

The whole issue started with the fact that the EGL tutorial needed to be
updated. To do that, I needed to update to version 6.0.1. And since I
decided that the "recommended" approach of a 22 hour download was not really
the right thing for me, I instead needed to update using the alternate
methods. However, there was some confusion as to which alternate method I
needed to use. You see, I first tried to download the WDSC changes from the
WDSC site (>300MB for Standard Edition, >400MB for Advanced). As it turns
out, though, these changes are only for the iSeries portion of WDSC. They do
not update the "base" portion of the Rational development tools, and it is
the base portion that houses the EGL toolkit (including the tutorial I was
trying to test). In order to update that part of the tool, I had to go
through a completely different process and that process wasn't quite soup
yet (the version I was directed to meant setting up an internal HTTP server
just to serve up the fix packs).

The bright side is actually twofold. First, the EGL team got together and
got me a DVD with the Rational product updates, which proved that the local
fixpack approach is viable. Second, the EGL folks assure me that they
recognize the need for a centralized download and distribute technique for
delivering fixpacks, and they're working to make this method one of the
standard methods of fixpack dissemination.

The downside is of course the fact that this isn't already in place. I have
a version of WDSC where the Rational parts are at 6.0.1, and the WDSC bits
are at 6.0.0. To be perfectly honest, while I understand that the Rational
team and the WebSphere team may have different priorities, that sort of
crosstalk shouldn't affect me, the end user of WDSC. Someone needs to be
responsible for the interoperability of these product lines, making sure
that at the end of the day the WDSC user has one place to go for all fixes,
be they Rational- or WebSphere-originated, and that person needs to have a
sense of what it takes to deliver products to the SMB users which IBM
professes to be courting. Requiring every machine to download 1.8GB is not a
viable solution, nor is having to go out and find multiple fixpacks to
download and install on each machine. As I said before, the EGL folks assure
me this is in process, so let's see what they do.