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

["Samuel T. Harris" <sam_harris@hso.link.com>]

jim_snead wrote:
> 
> 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.

Historically, Summit has been only recently extracted from
the original Apex tool. I really don't think of them as
different tools most of the time since the integration
of the development environment and the configuration management
environment is so seemless.

> 
> > 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.

Please note that Summit/CM uses RCS internally.
It not the core which makes it feasible, but the wrapper.
Summit/CM uses a vastly different approach from CVS
yielding vastly different tool sets. Answering the
kinds of questions above should provide valuable
clues as to which tool set will be a better match.

> 
> > 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.

I agree that deliverables should be separate from the code.
That is why my Ada mains are in different subsystems
from the bulk of the code supporting the project.
I can also use separate subystems for operational loads.
In such an organization, a project subsystem produces
Ada main executables. This subsystem, along with many
other project subsystems provide all the necessary
components for a load (data points, config files, etc.).
The operational subsystem is responsible for gathering all
these load build elements together into a single shrink-wrapped
load area. This area is then used for delivery to the customer.
Apex provides a healthy array of customization points to
automate the process if one so chooses.

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

Apex does not preclude using symbolic links.
Use then when they make sense. Indeed, I have had
occasion to make artificial subsystems when the content
of views were only symbolic links. Although not official
supported, whenever I check-out one of these links, Apex
has always traversed to the original subsystem for the CM
functions. In this way, I am not limited to a single
subsystem architecture but can support multiple organizational
schemes to support different kinds of users.

> 
> Overall I think (1) is a weak point.

We have backups as well, but they take time to recover. If a disk
crash takes out an entire subsystem and its views, then I have
hundreds of developers who can't work while the disk is reconstructed
from backups. Spreading the exposure keeps us going even while
the crashed disk is replaced and reconstructed because most of my
views are still around. This has paid dividends more than once in
actually practice.

> 
> > 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.

Using configuration files (lists of views) makes managing the
growing complexity of imports a breeze. The problem with lots
of little subsystems is the number of view imports required to
hook everything together. In other words, a fine namespace
involves lots of names. Using configuration files, many related
views are managed as a single entity. This get me back to
a coarse namespace with just a few names to be tracked.

As to the monolithic engine breaking, we've seen this happen
on more than one occasion due to disk crashes. I think it
just makes sense to limit exposure by dividing content.

With the advent of Clearcase integration into Apex and the
availability of RAID storage, these considerations deserve
another look.

> 
> > 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.

You'll get no argument from on on that!


-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"