Re: Is Apex dead as an environment for Ada & Java?

[jim_snead <basswoodNObaSPAM@my-deja.com.invalid>]

In article <3842C457.CBC87C2@hso.link.com>, "Samuel T. Harris"
<sam_harris@hso.link.com> wrote:
> > <snip>
> I've used Apex since its inception and its R1000 predecessors
> for years before that. I have found from experience that subsystem
> design is more about the flow of work than about the organization
> of code.
> While the tips given by Jim Snead are valuable, the concerns
> they address are not my primary concerns when I'm allocation
> subsystems to support a project. The organization the teams
> is primary. How many developers are involved? How are the
> developers partitioned into teams? What manager layers
> are involved in inter-team coordination? What are the logistics
> involved in the scheduling of each team's releases?

From the marketing claims this seems to be the job of Rational
Summit and not Apex.

> As many have alluded to, Apex is overkill for a small project.
> Apex shines for huge projects. And once in place in an organization
> to support a single huge project, then it is already available
> for the small ones as well.

I also believe that tools such as CVS may work for a huge project,
but I need more info to support this claim. Apparently there are
good graphical front ends to CVS, including emacs.

> I'd also like to add some technical attributes I've come to
> appreciate over the years.
> 1. The configuration management information resides in the
> subsystem. Each view uses it to generate its content. Since
> the subsystem and views can have different physical storage
> locations, I can spread by stuff around and limit my exposure
> to a disk crash.

I believe other solutions to this include redundant disks,
nightly backups, etc. I think Apex wants you to also place
executables in subsystems. I typically place all object files
and images away from the source code. This would prevent
applications from mixing with source code.

Unix symbolic links are also useful for assigning code to
various mounted file systems.

Overall I think (1) is a weak point.

> 2. Each subsystem is a self-contained configuration management
> area. I don't not have to be dependent on one single monolithic
> CM engine. This also limits my exposure to CM related problems.

Either it is a single monolithic engine or you will have to
do the maintenance imports on lots of little monolothic
engines.  For a large project, I would much rather do the
first.  What is the expectation, that a monolithic version
controlled code base might break if you put too much code into it?
I have not seen evidence of this occurring.

> 3. The clear separation between subsystems provides important
> configuration management controls and enforces a minimal level
> of discipline upon developers. I also like the use of histories
> instead of free-for-all branching supported by other tools.
> I can branch in Apex with histories, it just takes more work,
> and therefore more thought on just what exactly I need to do.
> As a parting thought, I do really miss that Ada command-line
> environment on the old R1000's.

I don't think anyone would recommend free-for-all branching.
Here is the way to do it in CVS:

 CVSROOT
    - history1
         - subdir1
         - subdir2
    - history2
         - subdir1
         - subdir2

 Integration "view" which brings together different branches
    - history1-subdir2
    - history2-subdir1

The key thing to remember is that histories or branches
are top-level entities that must be planned for, residing
close to the root of the hiearchy.  The reason people
have problems with branching is that it cannot be an
afterthought.



* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!