Tuesday, December 11, 2001 11:05 AM
Although the effort put into this "review" is appreciated, it is very misleading. There are some misleading statements and incorrect conclusions in the above, so I will attempt to address them here.
EJB deployment - the fact that WTE is so nicely integrated with VAJ is a big benefit during development, but it does not releive the developer from the responsibility for knowing how to deploy his application in his chosen production environment. If a developer can't do that, it is no fault of VAJ. Just because VAJ make sit easy to test/debug doesn't mean you shouldn't learn your production deployment server.
Also, I don't know what the author is talking about when he mentions some additional JARS necessary for deploying an EJB client. There is nothing special needed to do so for EJBs developed with VAJ - no more than is required for deploying any EJB application.
JSP integration - Integrating JSP in your application in VAJ is as easy as placing the .jsp files in the appropriate location. It is true that VAJ does not include a JSP editor, although the Scrapbook can be used edit any arbitrary text file. But a good JSP editor is a separate beast from a good Java editor. I suggest you look at some of the tools suh as HomeSite that are designed for editng HTML/JSP files.
GUI builder (VCE) - the VAJ VCE does allow you to make changes to the generated code, but within specific places in teh code. You can not just go changing things however you want - but the places where you can insert your own code are plentiful and well marked. True, you can't usually build an entire application "just by clicking," but VAJ in no way forces you to try to do that.
Debugging - I don't know what is meant by "You cannot set object breakpoints" but there are no types of breakpoints other than in anonymous inner classes that I can think of that VAJ does not allow.
J2EE Integration - It is simply not true that VAJ has no integration with app servers other than WebSphere. There exist toolkits for running both Tomcat and WebLogic in VAJ, and I have also seen JBoss running in VAJ.
Open API - The tools API provided in VAJ is very safe and does not "mess with" the repository. It provides access into the code that is stored in the repository, among other things. It is somewhat limited in that it does not allow you to modify the editors of VAJ, for example.
Version control - If you are a large team, that is exactly what ENVY (the repository server) and VAJ Enterprise were designed for. In fact, the larger the team the more effective and the better the payoff for investing in VAJ Enterprise. VAJ has consistently won awards from magazines, etc. in the "Enterprise" Java dev tool category, with many specifically citing its team source code management as a big factor. There is absolutely no basis for the suggestion that it does not suit large teams well.
Also, the statement "The repository is flaky" is unfounded. It goes against years of experience of those who have used ENVY (not just in VAJ). The repository is rock-solid and is not uscceptible to corruption unless there are network or hardware problems. This topic has been addressed both in this VAJ FAQ and on the newsgroups many times.
Another blatantly incorrect statement is that the workspace is a "local repository." It is not. See How does the repository/workspace combination work? for details on the workspace/repository relationship.
The ClearCase integration works pretty well, based on many people's experience. the accusations of it "simply not working" are certainly misguided, since I use it every day and it certainly does work. In fact, IBM added many requested features in version 3.5 that make the integration with external SCM tools more useful in VAJ.
Unfortunately, it is misinformation like this that can lead to poor decisions regarding choice of tools. VAJ may not be for everyone or every project, but you have to know all the correct facts before you can make a good decision.
Many of the items I addressed are likely a result of misunderstanding and/or misconfiguration. Some are probably the result of not taking the time to read the appropriate documentation or do a little research.