J2EE development and the 'evil WSAD legacy'

Around 2 years ago, I read a blog from a prominent software engineer in Melbourne (Jon Eaves) who posted about the 'evils' of Websphere Application Developer - having never used it, I read with curiosity and this reaffirmed my own development management of the team I was running at the time, in using: IntelliJ for an IDE, Maven for an independent test/build/development management system, and predefined, one-per-developer based IBM Webpshere Application Server (to which developers deployed to).

2 years forward (and as mentioned before, working on a legacy J2EE project) - I am using IBM's Eclipse2.0-based WSAD and a 1 hour + ANT development management system. After using it for a week, there are several key characteristics of WSAD which seem to engender poor code and development practises:

• In-built pseudo 'test' Websphere Application Server; what is the rationale in deploying to a IDE-based server? if everything deploys what has this actually proven? it has not been deployed on a Websphere Application Server and does not mitigate any of the risk associated with this. If anything, it promotes point-and0click testing and runtime debugging to be used as a substitute for unit testing. A better idea would be to have WSAD / RAD, etc. to have an extensible / callable EJB container that could be invoked off a unit testing framework such as JUnit, TestNG such that unit tests of legacy EJB2.0 code actually be tested. Assumptions regarding the full application deployment could then be verified on developer instances of WAS (and with integration tests).
• Non-standards based directory structure; if WSAD / RAD is going to provide Wizards to set up a new project - then conform to the industry standards in terms of directory structure, or at least allow any directory structure to be used. Currently, WSAD imposes a directory structure.
• Non-standards based artifact generation. Upon seeing the monolithic ANT development management process, I thought, I would be easy able to refactor the constituent jars, wars, and ejbs of the project. Unfortunately, this is not possible because IBM introduces its own bindings in the ejb-jar.xml such that it does not even conform to the schema - nonetheless it is able to be deployed on WSAD, WAS. Now only through WSAD (or by calling WAS libraries) is a deployment possible - complete vendor lock-in!
• Loose intra / inter project error checking - WSAD allows projects to have cyclic dependencies - when is this ever a maintainable approach? Error checking within a project is also poor (somewhat an artifact of Eclipse2.0).
  
• Extremely poor IDE responsiveness / performance on projects with multiple modules.
  

The 'evil WSAD legacy' results :- J2EE projects that are WSAD-bound (i.e. not able to develop / develop in any other IDE), poorly defined, poorly error-checked, and poorly tested. Of course, this is somewhat dependent on the developers that worked on the project in the first place - but with WSAD's loose industry compliance - it is difficult to see how any significant J2EE project will be maintainable in the long run if it has been developed, and continues to be devloped on WSAD.

So what do all the projects that have been run on WSAD do in the next 2-3 years when dealing with this legacy unmaintanenable code ...