Re: VAJAVA vs CODE/400 -- JAVA400-L

Shawn,

We use CVS and with VAJ it is a pain, but not a show stopper.   I do think 
the author of that piece is exaggerating the problems with diff/cvs/Vajava. 
With the version of diff we use it is not a problem at all. There is also a way 
to get CVS to look like VSS but I have not tried it with VAJava. Given a 
choice, I would take VAJava's merge over CVS'.

I am not trying to push you to use VA/Java, but I do get to see both sides 
of this daily. VA/Java is good when you are analyzing complex systems.  The 
others are good a quick changes.  Many times another developer has said 
"you have to do all that for this one little change".  Same people also say 
things like "What made you think to look at Oracle's connection package for 
Clob support?"

David Morris

>>> shawn@boxity.com 06/18/01 02:54PM >>>
The last time I tried to install VAJ was version 3.0.2.  The installation
twice halted the system (NT Server 4.0, SP6a), which is very rare under NT
(couldn't kill the running processes).  A previous install of a version 3.0
did actually get itself off the ground, but even with the latest service
packs installed it was not usable (it regularly stopped responding, and I
lost the source code I was testing with).  Unfortunately, these issues are
not related to usability, such as a NoClassDefFound, which would have been
resolvable.  My installation machines have all been at least PIII 733 mHz
machines with at least 256mb memory loaded with NT 4.0 at the latest service
pack level.

My preference would be to stick with IBM, and I would prefer also to use an
IDE, but I'm hesitant to spend more money to upgrade to a later version of
VAJ which I have no confidence can even install successfully, and this is
one specific area which needs work.  Based on my experiences, I am surprised
to hear that anyone is successfully using VAJ, so maybe I will consider
upgrading to 3.5, and the Linux availability for VAJ provides an additional
compelling reason to try it again.

One usability concern I've had with VAJ, and one which is echoed in the
article "Linux-Friendly VisualAge for Java" linked directly from IBM's VAJ
Info page
(http://www-4.ibm.com/software/ad/vajava/about/v35/vaj35platforms.html), is
that source code is not stored in the file system, but rather within VAJ's
repository, so data corruption (or even intended behaviour of the product)
can alter/damage/destroy your source code.  Here's an excerpt:

***
But woe to you if you need to incorporate an outside technology into your
development process. The only way to expose your project to the outside
world is by exporting either source code or bytecode. If you can't already
see the train wreck ahead, let me provide a simple example which immediately
confronted me.

The project I am currently working on is stored in a remote CVS repository.
If I want to use VisualAge on my project, I have to import the entire thing
into the VisualAge repository. When I'm finished making my changes, I need
to export the entire project (or, if I've kept track of which classes I've
modified, I can just export those) back to the file system. When the code is
exported, all the original formatting, warts and all, is reworked to conform
to the VisualAge formatting specifications. Unfortunately, this tends to
confuse diff to no end, rendering the merge- and change-history capabilities
of CVS/RCS completely useless. My response to IBM vis-�-vis the wisdom of
the repository approach would be an invocation of the Hippocratic oath:
First do no harm. If a feature is not useful, you should be able to ignore
it. It should never stand in the way of using the entire product.
***

Has anyone had any problems with this model?

Thanks,
Shawn

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---