Image

Imageluciphah wrote in Imagejava_dev 😯confused

WSAD/EJB/CVS

I decided to make this a separate post on java_dev, as I'd appreciate some
response if anyone has any experience in this area. The original post was here.


Our tool of choice for creating our masterpiece is WebSphere Studio
Application Developer (hereinafter referred to as WSAD to save my
keyboard, fingers and time), version 5.1.2. Our solution makes use of
all kinds of things – JMS Queues, Message-Driven Beans, Entity Beans
(using Container-Managed Persistence), Session Beans. I'm new to all of
this, having been shielded from it up until recently, but WSAD
seemingly does a lot of work for you. It has Rapid Application
Development (RAD) tools that allow you to concentrate on creating the
Entity Beans while it does all the RMI stubs, Local Interface and
LocalHome Interface (do I sound like I know what I'm talking about
yet?).


We're using CVS for source code control, which is also integrated
into WSAD, which is based on Eclipse. Now, apparently there's a problem
in here somewhere. A lot of code was being worked on by the previous
developers and not checked into CVS because they were getting a lot of
conflicts. Instead they were beavering away on their local machine,
copying the changes over to the other developer's workspace and getting
them to sync with CVS. The reason, as I understand it, was that when
the RAD tools were used, things like the following (completely
fabricated example) would be auto-generated:


package com.example.foopackage.ejb;
/**
 * Local Home interface for Enterprise Bean: Something
 */
public interface SomethingLocalHome extends javax.ejb.EJBLocalHome {
  private Long attribute_123456;

  public void setNumber(Long l) {
    attribute_123456 = l;
  }

  public void getNumber() {
    return attribute_123456;
  }
}

I've yet to actually see an example of this, but I can believe it.
Apparently the problem was that a lot of metadata is stored in the .metadata
directory of WSAD, so when two developers changed the structure of the
same EJB, the resulting changes in it and the generated code conflicted
and changed Rapid Application Development (RAD) to Conflict Resolution
Application Processing (CRAP). OK, I just made that last acronym up.
Also, it wasn't sufficient just to cvs update because the changes in the code wouldn't be reflected in the metadata.


Now I refuse to believe that of the thousands of people who have
used WSAD for Enterprise Java projects, no-one anywhere has come across
this problem except us. And if that is indeed the case, surely someone
somewhere has a solution. Anyone? Anyone?

LJ Video