Is Apex dead as an environment for Ada & Java?

Is Apex dead as an environment for Ada & Java?

[jim_snead]

I have been studying the Rational Apex product
as an Ada 95 and Java development environment.
Apex has an unusual feature called "subsystems"
which to me seems quite useless.

Apparently the notion is that you can place related
pieces of software into a subsystem, which is a
directory structure with strict naming conventions
(ends with a *.ss which nests other directories).
Other developers can place their own software into
another subsystem as a library.  The "subsystem"
seems to be a legacy organizing feature from
archaic software practices.

For any practical development in Java or Ada 95,
this notion seems particularly baroque and
antiquated.  With Java, the package namespace is the
organizing feature. Even though Rational sells an
Apex for Java, it is beyond me how subsystems would
even begin to work with Java. I guess that one
could put all of an organization's Java source libraries
into a single subsystem. But then what is the point
of a subsystem? In the same way, I believe that Ada
package hierarchies are sufficient to avoid the
need for multiple subsystems.

Why would anyone consider paying money for Apes
when it does not pay any attention to common
Java or Ada 95 deployment philosophies? Or am I
missing something?  (I do not care at all about
C or Ada 83).



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

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

[Martin Dowie]

jim_snead wrote:

> I have been studying the Rational Apex product
> as an Ada 95 and Java development environment.
> Apex has an unusual feature called "subsystems"
> which to me seems quite useless.
>
> Apparently the notion is that you can place related
> pieces of software into a subsystem, which is a
> directory structure with strict naming conventions
> (ends with a *.ss which nests other directories).
> Other developers can place their own software into
> another subsystem as a library.  The "subsystem"
> seems to be a legacy organizing feature from
> archaic software practices.

> For any practical development in Java or Ada 95,
> this notion seems particularly baroque and
> antiquated.  With Java, the package namespace is the
> organizing feature. Even though Rational sells an
> Apex for Java, it is beyond me how subsystems would
> even begin to work with Java. I guess that one
> could put all of an organization's Java source libraries
> into a single subsystem. But then what is the point
> of a subsystem? In the same way, I believe that Ada
> package hierarchies are sufficient to avoid the
> need for multiple subsystems.

>
> Why would anyone consider paying money for Apes
> when it does not pay any attention to common
> Java or Ada 95 deployment philosophies? Or am I
> missing something?  (I do not care at all about
> C or Ada 83).

(pedantic point - they place their code in as a 'view' not a library)

for small systems one subsystem would be enough but for the large embedded
systems i
work with subsystems are pretty useful. apart from adding a layer of
organization to the
views - you have to have somewhere to put the views. so, either the tool
dictates how to
name such repositories which everyone must follow (automatically), or you make
up your
own rules (and every engineer will have their own preference, or worse, every
engineer in
every project!) so that writing your own tools becomes just that little bit
harder. a
common approach is to have a subsystem per piece of hardware your software
monitors/controls (thread?/process?/task?), other subsystems to deal with
classes,
shared data stores and inter task (process/thread) communications plus a 'main'
subsystem to pull them all together in one executable.

the real point about the subsystem is that this is where the repository for all
the code is
(including a note of what histories are available) - the views do not
automatically go
looking for each other to see which view is using which compilation unit at
whatever issue
or history.

Apex describe them on their web site -
"Rational Apex provides a framework for defining architectural components, known
as Rational Subsystems�. These subsystems integrate with the Rational Apex
version control system and with Ada 95 package hierarchies. Rational Apex
prevents undesirable code references by controlling visibility among
architectural components. Attempts to improperly reference units results in
compile time error messages. In this way, subsystems enable users to
automatically express and enforce the large-scale structure, or architecture, of
their applications."

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

[jim_snead]

In article <384127A5.61431A14@dowie-cs.demon.co.uk>, Martin Dowie
<martin@dowie-cs.demon.co.uk> wrote:
> common approach is to have a subsystem per piece of hardware your
> software
> monitors/controls (thread?/process?/task?), other subsystems to

Here is an essential problem with Rational
subsystems. Say you do have a software
subsystem for each one of your hardware items.
Let us call them Gamma and Omega.

So the Gamma subsystem implementors create a
couple of packages called "Logging" and "Debug".
These are not meant to be used outside of the
Gamma subsystem so they are not made visible
to the outside world via whatever mechanism
Apex uses.

Now say that the Omega subsystem has their
own internal packages called "Logging" and "Debug".
The Omega team goes ahead and develops these as
well, oblivious to the rest of the world.

Now the subsystem that you propose to integrate
these other subsystems comes along and tries
to link Omaga and Gamma into a single exec.
Of course, this won't work because of name clashes
between the hidden packages. Time to use another
approach!


Now here is how you do it with Ada 95. First create
a single subsystem repository. Next create two package
hierarchies called Gamma and Omega and organize these
into a directory structure of your choosing.

For the private packages, you create (ahem) private packages.

    private package Gamma.Logging is ...
    private package Gamma.Debug is ...

    private package Omega.Logging is ...
    private package Omega.Debug is ...

This Ada 95 approach apparently solves the original
subsystem problem better than the legacy Apex solution
does because it will eliminate the integration error while
solving the privacy problem.


Apex "Views" (i.e. controlled directories) and
"Histories" (i.e. branches) plus version control
are all that are required for development.
The concept of a subsystem is
counterproductive as it adds another variable to an
overspecified set of equations. If Apex subsystems
are to be used for anything other than an elaborate
Ada Include Path, it is certainly over-hyped for
Ada 95 use.  Apex subsystems add no value
in guaranteeing integration success. Ada 95 got it
right, and the old guard tool vendors are trying
to create FUD in how to correctly integrate large
software projects.




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

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

[mike_zebrowski]

Apex subsystems help prevent circular references.
Ada95 naming coventions do not.

Mike Zebrowski


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[jim_snead]

In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com
wrote:
> Apex subsystems help prevent circular references.
> Ada95 naming coventions do not.
> Mike Zebrowski
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Here is an approach to prevent circular dependencies
which is enforcable by using an Ada 95 compiler.

Say you have a package hierarchy called Kappa and one
called Delta.  Delta is allowed to "with" anything in
Kappa but the converse is not true. The Kappa source
is located in the path called /code/Kappa and the
Delta source is located in the path called /code/Delta.

The enforcement procedure using the Ada compiler
is to allow the Delta developers the path:
  ADA_INCLUDE_PATH /code/Delta:/code/Kappa

The Kappa developers are allowed this path:
  ADA_INCLUDE_PATH /code/Kappa

Note that the Kappa team can try all they want
to "with" Delta code. They won't succeed unless
the software lead grants them the Delta path.

This approach is simple and enforceable. I don't
like the fact that Apex has features as complicated
as subsystems to accomplish this simple effect.
The tool effectively locks you into a specific approach
and you become a captive Apex customer because
of some outrageous marketing features.


In any event, there are many valid reasons to have
circular dependencies. See Java for lots of examples.



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

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

[reason67]

In article <0a0133f8.7900d89e@usw-ex0102-015.remarq.com>,
  jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote:
> In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com
> wrote:
>
> This approach is simple and enforceable. I don't
> like the fact that Apex has features as complicated
> as subsystems to accomplish this simple effect.
> The tool effectively locks you into a specific approach
> and you become a captive Apex customer because
> of some outrageous marketing features.


The reason for subsystems is to encapsulate components withing a
software hierarchy. For instance, if I was working on a simple Fighter
simulation, I might want a subsystem for universals_types,
low_level_utilities, then build subtrees based on common radar
functionalities, common flight functionalities, weather, etc. Then, for
example in the flight, I could break i down further into flight_common,
cockpit_displays, aerodynamics, etc. etc.

What I gain is the ability to enforce a design onto 50 - 100 developers.
This would prevent a flight developer from using a subprogram developed
by a weather developer. This enforces loose coupling between unrelated
features. If the weather developer needs to eliminate or modify his
subprograms, he is guarenteed not to effect the other in unrelated areas
of the simulation.

Can I do this other ways in Ada95? Sure. But I can only do it in Ada95
by enforcing a coding requirement on the developers, and not just a
design requirement. (your package heirarchy example).

Subsystems serve another purpose as well, as someone else pointed out,
Apex code exists in views. The code is shared in a subsystem and
implemented in views. The Subsystems enforce the CM.

None of this makes Apex a requirement for Ada95 obviously and you may
consider the overhead to be too great or the cost prohibitive, but it
certainly does not mean that Apex subsystems serve no purpose or are
antequated. I have always found them to be quite useful on large
projects.
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[jim_snead]

In article <81u6sh$l7k$1@nnrp1.deja.com>, reason67@my-deja.com wrote:
> The reason for subsystems is to encapsulate components withing a
> software hierarchy. For instance, if I was working on a simple
> Fighter simulation, I might want a subsystem for universals_types,
> low_level_utilities, then build subtrees based on common radar
> functionalities, common flight functionalities, weather, etc.
> Then, for example in the flight, I could break i down further into
> flight_common, cockpit_displays, aerodynamics, etc. etc.

These are way too big of chunks for subsystems.  I would
say a hierarchy (i.e. individual subsystem) would be examples
such as the Linux operating system, the source code to GNAT,
or the Mozilla-Netscape source.  Why on earth would you want
to apportion these into smaller subsystem chunks?

> What I gain is the ability to enforce a design onto 50 - 100
> developers.
> This would prevent a flight developer from using a subprogram
> developed
> by a weather developer. This enforces loose coupling between
> unrelated
> features. If the weather developer needs to eliminate or modify his
> subprograms, he is guarenteed not to effect the other in unrelated
> areas of the simulation.

Apparently Apex does allow the mutual importation of subsystems.
I don't understand, does Apex enforce this policy or doesn't it?
I have my include paths as an example to rigidly enforce
such a policy without requiring Apex.

> Can I do this other ways in Ada95? Sure. But I can only do it in Ada95
> by enforcing a coding requirement on the developers, and not just a
> design requirement. (your package heirarchy example).
> Subsystems serve another purpose as well, as someone else pointed
> out,
> Apex code exists in views. The code is shared in a subsystem and
> implemented in views. The Subsystems enforce the CM.

Here is the way to do it in CVS

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

- Integration "view"
    - history1-subdir2
    - history2-subdir1

I doubt Apex does it any different. In which case this is
very basic functionality. In my example, the CVSROOT
enforces the CM responsibility.  I suppose
you could have different CVSROOT paths which
would be the equivalent of different subsystems.
But I would only do this if I knew I was
going to develop both Linux, GNAT, and Netscape
at the same time. Which is very doubtful.

> None of this makes Apex a requirement for Ada95 obviously and you
> may consider the overhead to be too great or the cost prohibitive, but
> it certainly does not mean that Apex subsystems serve no purpose or
> are antequated. I have always found them to be quite useful on large
> projects.

No I am only trying to figure out a path forward.  Rational
has many products that seem to cannibalize each other
such as Apex, ClearCase, and Summit.  Each one of these
is claimed to be the way to go for large software systems
development.




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

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

[Martin Dowie]

> I doubt Apex does it any different. In which case this is
> very basic functionality. In my example, the CVSROOT
> enforces the CM responsibility.  I suppose
> you could have different CVSROOT paths which
> would be the equivalent of different subsystems.
> But I would only do this if I knew I was
> going to develop both Linux, GNAT, and Netscape
> at the same time. Which is very doubtful.

doubtful for you - but exactly the sort of thing i am currently involved in...

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

[reason67]

In article <1761dd4a.3f28b0f0@usw-ex0101-008.remarq.com>,
  jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote:


> These are way too big of chunks for subsystems.

It was an example, not an actual software architecture.

> I would
> say a hierarchy (i.e. individual subsystem) would be examples
> such as the Linux operating system, the source code to GNAT,
> or the Mozilla-Netscape source.  Why on earth would you want
> to apportion these into smaller subsystem chunks?

Loose coupling, division of labor, information hiding, etc. If you limit
these chunks with well defined interfaces (views have the ability to
only export certain specs in them), you can enforce a software
architecture and loose coupling.

> Apparently Apex does allow the mutual importation of subsystems.
> I don't understand, does Apex enforce this policy or doesn't it?
> I have my include paths as an example to rigidly enforce
> such a policy without requiring Apex.

Well, you do not import subsystems, you import views. Apex has a feature
called "mutually importing views." According to a tech rep I asked about
this in 1995, it was a feature added to make a sale to a big company
that wanted to transition legacy Ada 83 to Apex for Ada83. I have worked
in using Rational Apex in 5 companies now and have only once seen that
feature used. It was used to separate a subsystem that contained
hundreds of Ada packages but was tightly coupled into 5 subsystems where
all the views of a particular tower were mutually importing. It was a
bad design that led to this use and this was legacy code. I have never
seen a new design ever consider using mutually importing views.

> Here is the way to do it in CVS
>
> - CVSROOT
>     - history1
>          - subdir1
>          - subdir2
>     - history2
>          - subdir1
>          - subdir2
>
> - Integration "view"
>     - history1-subdir2
>     - history2-subdir1
>
> I doubt Apex does it any different. In which case this is
> very basic functionality. In my example, the CVSROOT
> enforces the CM responsibility.  I suppose
> you could have different CVSROOT paths which
> would be the equivalent of different subsystems.
> But I would only do this if I knew I was
> going to develop both Linux, GNAT, and Netscape
> at the same time. Which is very doubtful.

You misunderstand subsystems. Let me give a simple example:

I am building a controller that communicates over TCP/IP and uses X
windows to talk to the user. I separate the code into the following
subsystems:

low_level_components.ss
communications.ss
command_and_control.ss
user_interface.ss

In each view I have a release called: block1.rel and a working view
called block_2_working.wrk.

the heirarchy of the subsystems is:
                   low_level_components.ss
                       /          |         \
              user_interface.ss   |    communications.ss
                        \         |         /
                       command_and_control.ss

At the high level design level, the interface between the user_interface
and the command_and_control is defined, and the interface between the
communications and command_and_control. The Ada specs are put into place
and in the views. In low level design, common algorithms and types are
defined and placed in low_level_components. Coding then can progress on
user_interface, communications, and command_and_control without any
impact on one another, unless there is a change to the interface defined
earlier. The coupling between the views in the subsystems are minimized.

(So, I assume this would be more like your subdirectories in a given
history, where the histories would be more like the views or releases
(although not exactly the same thing)).

So, lets say I have finished with Block 1 and want to move to Block 2 of
my software. I can release the Block_1 tower and create new block 2
working views. these views can import the block 1 releases until the
block 2 interfaces are stable and then change the imports to the
stablized block 2 views. This it one reason for multiple views in a
subsystem.

Another is that Bob and I are working on communications. Bob and I make
out own views off of an integration view, work in our own views and then
import out tested changes back into the integration view when completed.
This is not rocket science or anything, I have never seen a CM system
where the equivolent was not possible, the key to the Apex IDE is that
it is integrated into the IDE, which I have not seen elsewhere.

> No I am only trying to figure out a path forward.  Rational
> has many products that seem to cannibalize each other
> such as Apex, ClearCase, and Summit.  Each one of these
> is claimed to be the way to go for large software systems
> development.

Brief history of Rational Software. In the beginning there was Rational,
they made Rational R1000's which were a hardware/software Ada 83
development system. They had subsystems and views. R1000's were dogs.
They were slow and ineffeciant and broke often, but besides that where
pretty good development platforms. Rational bought Verdix and became
Rational Software. Using the VADS compiler, they incorperated alot of
their R1000 environment into the compiler, thus decoupling it from the
Rational Hardware. Apex was born. Apex is an IDE, Summit is an add on to
that IDE. ClearCase is a CM product. It can be used with or without
Apex.  So "the way to go" depends on what you are looking for. If you
want an IDE, ClearCase, SoDA, or Rose are not the way to go :)

I hope this answers your original question:

> Why would anyone consider paying money for Apex when it does not pay
> any attention to common Java or Ada 95 deployment philosophies? Or am
> I missing something?
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[jim_snead]

In article <820p6p$hb9$1@nnrp1.deja.com>, reason67@my-deja.com wrote:
> Brief history of Rational Software. In the beginning there was
Rational,
> they made Rational R1000's which were a hardware/software Ada 83
> development system. They had subsystems and views. R1000's were
> dogs.
>They were slow and ineffeciant and broke often, but besides that here
> pretty good development platforms. Rational bought Verdix and
> became
> Rational Software. Using the VADS compiler, they incorperated alot
> of their R1000 environment into the compiler, thus decoupling it from
> the
> Rational Hardware. Apex was born. Apex is an IDE, Summit is an add
> on to
> that IDE. ClearCase is a CM product. It can be used with or without
> Apex.  So "the way to go" depends on what you are looking for. If
> you want an IDE, ClearCase, SoDA, or Rose are not the way to go :)

Piecing the tools together, I gather Apex is the back-end which uses
command line arguments such as "apex check_in <file>".
This then updates a RCS repository. Then they use emacs to
act as the default user interface (IDE) which enables
us to conveniently pass on the command line arguments to Apex.

Thanks for the insight. I have a pretty good idea of how
to proceed.

> I hope this answers your original question:
> > Why would anyone consider paying money for Apex when it does not
> pay
> > any attention to common Java or Ada 95 deployment philosophies?
> Or am
> > I missing something?
> ---
> Jeffrey S. Blatt
> Sent via Deja.com http://www.deja.com/
> Before you buy.



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

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

[Samuel T. Harris]

jim_snead wrote:
> 
> In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com
> wrote:
> > Apex subsystems help prevent circular references.
> > Ada95 naming coventions do not.
> > Mike Zebrowski
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> 
> Here is an approach to prevent circular dependencies
> which is enforcable by using an Ada 95 compiler.
> 
> <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?

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

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.

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.

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

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

[jim_snead]

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!

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

[John Duncan]

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

CVS is good, and physically it scales, but it takes a lot of work to make
CVS fit into your culture.  It is adapted for Unix/C environments, and it
leaves much to be desired/written.  A build environment would be nice, and
don't even try to say "make".

Look at the Vista 2 project at SRC.  There are many interesting ideas there,
some of which have been incorporated into commercial applications.

---

As far as the rest of this thread is concerned, I think that Jim Snead asked
a good question, which is "why does anyone use this expensive product", and
questions like that need to be asked.  But it is not the business of this
group to convince Jim that he should use Apex.  That is Rational's job.  And
the people who use Apex either have questioned whether they should or have
not.

There are open-source considerations that are as good for as many
applications as commercial packages are, and there are as many applications
that open-source tools don't support as commercial packages do not.  Some
people/companies prefer the commercial applications.  It works for them, the
answer was given.

In my opinion, it seems that there must be a subtle symbiosis in the parts
of Apex that make it better for some than for others, and it seems that it
has a following that dates back before the product got its name.

There is an obvious following for CVS and GNAT.  I personally hate working
with and configuring unix-style compilers, but as long as those are the free
ones, its what I'm stuck with.  But just because something can be done with
two different tools, it doesn't mean it gets done the same way.

-John

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

[reason67]

In article <81vh33$3o0$1@usenet01.srv.cis.pitt.edu>,
  "John Duncan" <jddst19+@pitt.edu> wrote:

> As far as the rest of this thread is concerned, I think that Jim Snead
asked
> a good question, which is "why does anyone use this expensive
product", and
> questions like that need to be asked.

Actually his question was "what is the purpose of Apex subsystems." I
don't think anyone is trying to sell Apex to him. I certainly am not, I
think it is incredibly overpriced personally.
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Robert Dewar]

In article <81vh33$3o0$1@usenet01.srv.cis.pitt.edu>,
  "John Duncan" <jddst19+@pitt.edu> wrote:

> CVS is good, and physically it scales, but it takes a lot of
> work to make CVS fit into your culture.

Well I suppose anyone can have a hostile "culture" to any
piece of software. Perhaps the "your" here is inappropriate.
A more reasonable statement might be "we found it took a lot
of work to make CVS fit into *our* culture." Our experience
has been that it has been very easy for people to learn to
use CVS.

> It is adapted for Unix/C environments

We have used it in a wide variety of operating system
environments including VMS, OS/2 etc.

> and it leaves much to be desired/written.

With no specifics that's not very helpful!

> A build environment would be nice, and
> don't even try to say "make".

Sorry no comprendo, it is definitely easy to integrate build
environments with CVS.

> There is an obvious following for CVS and GNAT.  I personally
> hate working with and configuring unix-style compilers

Not quite sure what you mean by unix-style compilers here, it
is more useful if you try to be specific.

> but as long as those are the free
> ones, its what I'm stuck with.

Actually not, you have an edu address right? You should contact
Rational, last time I knew they were making systems available
for small or no charges to universities, and certainly a version
of the Aonix compiler is available at no charge.

Clearly it is not the case that GNAT appeals only to the Unix
style of thinking (whatever that means), since we have many
customers on NT, who prefer GNAT to other alternatives
(especially interesting, since GNAT is significantly more
expensive than some of the alternatives on NT).

> But just because something can be done with
> two different tools, it doesn't mean it gets done the same
> way.

Not clear what you are referring to here ...


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[John Duncan]

Well, I started programming on a macintosh, and then I began to hate
everything else I had to use.  Sure, the mac itself is silly, but the
programming environments were so intuitive and easy to use...

-John

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

[Martin Dowie]

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

placing executables in the same subsystem/view as the main program is the
default option when linking - but this can be changed to leave the '.exe'
wherever you like.

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

[Samuel T. Harris]

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!"

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

[Aidan Skinner]

On Mon, 29 Nov 1999 18:40:56 -0800, jim_snead
<basswoodNObaSPAM@my-deja.com.invalid> wrote: 

>but I need more info to support this claim. Apparently there are
>good graphical front ends to CVS, including emacs.

The GNU Emacs (I tried XEmacs for a bit, but didn't like it, I don't
know how it compares in this regard, it's probably the same) front end
to revision control systems is wonderful. It's slightly better for raw
RCS than CVS, but there's very little difference visible to the user
except you can't undo check ins in CVS with it, but that's to be
expected because of the way that CVS works.

There's a GNOME front end to CVS (called Pharmacy) available from:
http://home.earthlink.net/~nawalker/pharmacy.html

I've been using it for a few days now, it's kind of confusing at first
but that's because there's practically no documentation and it's still
at 0.2.1

It could concievably be integrated with Glade (http://glade.pn.org),
the Gtk/GNOME GUI builder which has Ada '95 suppourt, a graphical
debugger (eg. DDD) built on top of GDB with the GNAT patches, and the
text editor of your choice to provide a complete Free[1] IDE that
would run on a modest (by current standards) machine (my p166 with 48Mb
of RAM handles it all with only a little discomfort caused by whole
screen redraws).

- Aidan

[1] I think I'll adopt the convention that Free is equivalent to
libre and free is equivalent to gratis.
-- 
http://www.skinner.demon.co.uk/aidan/
http://www.gla.ac.uk/Clubs/WebSoc/~9704075s/
"I could always suspend a few hundred accounts and watch what happens"

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

[Robert Dewar]

In article <slrn84amrj.22s.aidan@skinner.demon.co.uk>,
  aidan@skinner.demon.co.uk wrote:
> would run on a modest (by current standards) machine (my p166
> with 48Mb of RAM handles it all with only a little discomfort
> caused by whole screen redraws).


Not just modest, but drastically obsolete. For $1000 you can
get a 550Mz Athlon machine with 128 meg of memory that
conservatively should be a full four times faster than the
machine you are using. This is of course also off topic, but
it is worth reminding everyone that remarkable amounts of
computing power are available cheaply for Ada development
purposes. We recently (for about $2000) acquired a 750MHz
Athlon machine with 256 meg of memory and 30 gig of disk.
This machine runs a full two times faster than a 450MHz
Pentium III (thus the Athlon is equivalent to about a
900MHz Pentium III for this kind of processing, which
involves compiling, running tests etc). Be careful of
benchmarks in PC magazine etc, these benchmarks are heavily
weighted by graphics mucking and other stuff that is quite
irrelevant to typical Ada development.



Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <slrn84amrj.22s.aidan@skinner.demon.co.uk>,
>   aidan@skinner.demon.co.uk wrote:
> > would run on a modest (by current standards) machine (my p166
> > with 48Mb of RAM handles it all with only a little discomfort
> > caused by whole screen redraws).
> 
> Not just modest, but drastically obsolete. For $1000 you can
> get a 550Mz Athlon machine with 128 meg of memory that
> conservatively should be a full four times faster than the
> machine you are using.

Aidan is writing from a UK address, and things tend to be a bit more
expensive here (especially if you are a home user and don't get
corporate discounts).

The sort of machine you describe is the subject of reviews in the Jan
2000 PC Mag., the editor's choice is UKP 1299, about $2000. +VAT at
17.5%. The cheapest was UKP 1119.

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

[David C. Hoos, Sr.]

Aidan Skinner <aidan@skinner.demon.co.uk> wrote in message
news:slrn84amrj.22s.aidan@skinner.demon.co.uk...
> On Mon, 29 Nov 1999 18:40:56 -0800, jim_snead
> <basswoodNObaSPAM@my-deja.com.invalid> wrote:
>
> >but I need more info to support this claim. Apparently there are
> >good graphical front ends to CVS, including emacs.
>
> The GNU Emacs (I tried XEmacs for a bit, but didn't like it, I don't
> know how it compares in this regard, it's probably the same) front end
> to revision control systems is wonderful. It's slightly better for raw
> RCS than CVS, but there's very little difference visible to the user
> except you can't undo check ins in CVS with it, but that's to be
> expected because of the way that CVS works.
>
> There's a GNOME front end to CVS (called Pharmacy) available from:
> http://home.earthlink.net/~nawalker/pharmacy.html
>
> I've been using it for a few days now, it's kind of confusing at first
> but that's because there's practically no documentation and it's still
> at 0.2.1
>
<snip>
There is also tkcvs a tcl/tk interface, which I have been using for most
of this year -- I'll take a look at Pharmacy, though.

Tkcvs is available at:
http://www.teleport.com/~mokuren/tkcvs.html

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

[Martin Dowie]

> This approach is simple and enforceable. I don't
> like the fact that Apex has features as complicated
> as subsystems to accomplish this simple effect.
> The tool effectively locks you into a specific approach
> and you become a captive Apex customer because
> of some outrageous marketing features.
>
> In any event, there are many valid reasons to have
> circular dependencies. See Java for lots of examples.

Apex supports subsystems circular dependencies - it just forces you to be
explicit about it - and this may make you think about your design to see if it
is really necessary

i've worked with a number of companies who all use Apex in their own house style
- Apex DOES NOT lock you into anything!

p.s. i don't work for rational!

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

[jim_snead]

In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com
wrote:
> Apex subsystems help prevent circular references.
> Ada95 naming coventions do not.
> Mike Zebrowski
> Sent via Deja.com http://www.deja.com/
> Before you buy.

I found out that Apex allows mutually importable
subsystems, which is what I think the
circular refers to.  So much for strict enforcement.




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

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

[Samuel T. Harris]

jim_snead wrote:
> 
> In article <81s370$7am$1@nnrp1.deja.com>, mike_zebrowski@my-deja.com
> wrote:
> > Apex subsystems help prevent circular references.
> > Ada95 naming coventions do not.
> > Mike Zebrowski
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> 
> I found out that Apex allows mutually importable
> subsystems, which is what I think the
> circular refers to.  So much for strict enforcement.

Well, it is strict. Mutually imports require that ALL
the mutally dependent views be managed collectively.
In other words, if views x, y, and z are mutually 
dependent, then I cannot make a release of view x
by itself. I have to make a relase based on x, y, and z
at the same time. They are, in practical terms, a single
logical subsystem split between multiple actual subsystems.
So they are much more restricted than regular, non-circular
import dependencies.

One way to eliminate circular dependencies is to insure
each interface is in a separate subsystem from its users.
For instance, say I have two major code collections called
X and Y. They both interface with each other, so X provides
an interface which Y uses and Y provides an interface which
X uses. If X's interface in packaged with X's code and similarly
for Y, then we have a mutual import dependency.

However, if I split the interfaces out into separate subsystems,
say X_Iface, X_Model, Y_Iface, and Y_Model, then I eliminate
the circular dependencies. If all models have a separate Iface
subsystem, then I never get circular dependencies no matter
what the interface topology. This also alows a natural release
strategy of releasing updated interfaces independently. This
allows all models to progress to the new interfaces in succession.
This architecture is very flexible to a variety of scheduling
paradims.

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

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

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

[jim_snead]

In article <38441AAE.29B2D8@hso.link.com>, "Samuel T. Harris"
<sam_harris@hso.link.com> wrote:
> One way to eliminate circular dependencies is to insure
> each interface is in a separate subsystem from its users.
> For instance, say I have two major code collections called
> X and Y. They both interface with each other, so X provides
> an interface which Y uses and Y provides an interface which
> X uses. If X's interface in packaged with X's code and similarly
> for Y, then we have a mutual import dependency.
> However, if I split the interfaces out into separate subsystems,
> say X_Iface, X_Model, Y_Iface, and Y_Model, then I eliminate
> the circular dependencies. If all models have a separate Iface
> subsystem, then I never get circular dependencies no matter
> what the interface topology. This also alows a natural release
> strategy of releasing updated interfaces independently. This
> allows all models to progress to the new interfaces in succession.
> This architecture is very flexible to a variety of scheduling
> paradims.

So specs go into the IFace and bodies go into the Model subsystems?




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

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

[Samuel T. Harris]

jim_snead wrote:
> 
> In article <38441AAE.29B2D8@hso.link.com>, "Samuel T. Harris"
> <sam_harris@hso.link.com> wrote:
> > One way to eliminate circular dependencies is to insure
> > each interface is in a separate subsystem from its users.
> > For instance, say I have two major code collections called
> > X and Y. They both interface with each other, so X provides
> > an interface which Y uses and Y provides an interface which
> > X uses. If X's interface in packaged with X's code and similarly
> > for Y, then we have a mutual import dependency.
> > However, if I split the interfaces out into separate subsystems,
> > say X_Iface, X_Model, Y_Iface, and Y_Model, then I eliminate
> > the circular dependencies. If all models have a separate Iface
> > subsystem, then I never get circular dependencies no matter
> > what the interface topology. This also alows a natural release
> > strategy of releasing updated interfaces independently. This
> > allows all models to progress to the new interfaces in succession.
> > This architecture is very flexible to a variety of scheduling
> > paradims.
> 
> So specs go into the IFace and bodies go into the Model subsystems?
> 

One could do that, and I have considered this idea on several
occasions to limit recompilation impact imposed by new releases,
but that is not what I meant. The interface is a different package
from the model. The interface spec and body units go into a
separate subsystem from the model spec and body units.

Since you mentioned the idea of putting unit specs and bodies
into separate subsystems, I'll elaborate on this as well.
Even the advanced incremental compiler provided with Apex
provides little benefit when a new release is being made.
Conventional code organization keeps the spec and body of
a unit in the same place. On the surface, this seems a
natural organizational scheme. However, when a new release
is made because of strictly body changes, a new spec is
also released. This causes an unneccesary compilation impact.

Looking deeper into the problem, we can realize that the
separation of the spec and body in Ada provides an
equivalent opportunity to separate in code organization.
Keeping the specs and bodies in separate subsystems yields
some important benefits.

1) A view only needs to import spec views. Body views need
not be imported at all. Body views do need to be listed
in the link_with_configuration. One can envision a customization
which manages link_imports just like, but separate from,
regular view imports.

2) I can change the link_imports at will and suffer no
compilation effects (unless inline subprograms are in use).
I only have to relink. This allows me to rapidly try
different implementation options using a single set of
package specs.

This organization scheme also suffers from the following
disadvantages.

1) The separation of spec and body into two different
areas makes it clumsy for the developer. Two naturally
intimate units do not reside in the same place. Of course
this issue is mitigated with the superb navigation facilities
and can be handled by using "working" subsystems whose views
use symbolic links to "collect" related stuff together into
one place.

2) Immature code in the early stages of development will
not realize the benefits noted above. The specs of such
code change nearly as often as the bodies. Only mature
code with stable specs are candidates for this scheme.

I have given this issue much thought over the years.
I originally wanted to simulate the old R1000 facility
of spec views vs load views. A spec view had only
uint specifications. It could be related to many different
load views which had the unit bodies. The load view
also had specs, but they had to have the same content.
Since the spec view and load views were in the same
subsystem, this scheme did not suffer from the clumsiness
of their separation.

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

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

[Martin Dowie]

jim_snead wrote:

> In article <384127A5.61431A14@dowie-cs.demon.co.uk>, Martin Dowie
> <martin@dowie-cs.demon.co.uk> wrote:
> > common approach is to have a subsystem per piece of hardware your
> > software
> > monitors/controls (thread?/process?/task?), other subsystems to
>
> Here is an essential problem with Rational
> subsystems. Say you do have a software
> subsystem for each one of your hardware items.
> Let us call them Gamma and Omega.
>
> So the Gamma subsystem implementors create a
> couple of packages called "Logging" and "Debug".
> These are not meant to be used outside of the
> Gamma subsystem so they are not made visible
> to the outside world via whatever mechanism
> Apex uses.
>
> Now say that the Omega subsystem has their
> own internal packages called "Logging" and "Debug".
> The Omega team goes ahead and develops these as
> well, oblivious to the rest of the world.
>
> Now the subsystem that you propose to integrate
> these other subsystems comes along and tries
> to link Omaga and Gamma into a single exec.
> Of course, this won't work because of name clashes
> between the hidden packages. Time to use another
> approach!
>

couldn't happen in our world - we design first then code and our code matches
the names used in the design.

also - and this is a common approach NOT just applicable to using Apex - we
prefix application objects with the equipment name, so we would have Omega_Debug
and Gamma_Debug packages.

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

[jim_snead]

In article <384435B4.22876942@dowie-cs.demon.co.uk>, Martin Dowie
<martin@dowie-cs.demon.co.uk> wrote:
> jim_snead wrote:
> > Now the subsystem that you propose to integrate
> > these other subsystems comes along and tries
> > to link Omaga and Gamma into a single exec.
> > Of course, this won't work because of name clashes
> > between the hidden packages. Time to use another
> > approach!
> >
> couldn't happen in our world - we design first then code and our
> code matches the names used in the design.
> also - and this is a common approach NOT just applicable to using
> Apex - we
> prefix application objects with the equipment name, so we would
> have Omega_Debug and Gamma_Debug packages.

I am working with the current standard Ada so would likely enforce
Omega.Debug and Gamma.Debug.  However, I understand where
you come from with respect to choosing names in Ada 83.




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

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

[Robert Dewar]

In article <384435B4.22876942@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> couldn't happen in our world - we design first then code and
> our code matches the names used in the design.


But unless you have some design tool that prevents it, surely
the same name clash problems can occur, unless you do some
coordination of the single giant name space problem. I don't
see what design first has to do with this particular problem.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Martin Dowie]

>
> But unless you have some design tool that prevents it, surely
> the same name clash problems can occur, unless you do some
> coordination of the single giant name space problem. I don't
> see what design first has to do with this particular problem.

yes, of course, we use a tool - by doing the design first (using a tool)
we explicitly name our objects first and thus prevent the name space
problem described.

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

[jim_snead]

In article <0a0133f8.3baf10c0@usw-ex0101-001.remarq.com>, jim_snead 
wrote:
> Apex subsystems add no value
> in guaranteeing integration success. Ada 95 got it
> right, and the old guard tool vendors are trying
> to create FUD in how to correctly integrate large
> software projects.

I did not mean to imply that all of the old guard vendors
are not moving forward.  Just that the new vendors
such as GNAT,  Aonix, and Averstar seem to be creative
in coming up with interesting ideas and solutions.

For example, new integration approaches will be
required for software geared to  Ada JVM development.



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

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

[Robert Dewar]

In article <01a2e3cb.4316300b@usw-ex0101-005.remarq.com>,
  jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote:

> I did not mean to imply that all of the old guard vendors
> are not moving forward.  Just that the new vendors
> such as GNAT,  Aonix, and Averstar seem to be creative
          ^^^^

Ada Core Technologies please, I don't think that you can expect
a compiler to be creative in that sense :-)

> in coming up with interesting ideas and solutions.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Ted Dennison]

In article <01a2e3cb.4316300b@usw-ex0101-005.remarq.com>,
  jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote:
> I did not mean to imply that all of the old guard vendors
> are not moving forward.  Just that the new vendors
> such as GNAT,  Aonix, and Averstar seem to be creative
> in coming up with interesting ideas and solutions.

How is it that Rational is considered "old guard", yet Aonix is not?
After all, an incarnation of each of them was a bidder for the the Ada83
implementaion.

I suspect the endemic problem, *if indeed there is one*, is that
Rational's software engieering tools business has vastly overshadowed
their Ada business. Aonix's only other major business that I am aware of
is GUI builders and graphical software visualization tools. So instead
why not make the claim that each company's other business activities
color their approaches to problems in the Ada world? So Rational tries
to bludgen to death every problem with external software tools, while
Aonix spends an immense amount of effort on a nice GUI front end for
everything, yet doesn't bother to provide mundane stuff like
optimization options.

Averstar and ACT are newer, but that really just means that their main
corporate focus is still on their compilers.

Its a theory...

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Larry Kilgallen]

In article <82638m$cif$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> writes:

> Averstar and ACT are newer, but that really just means that their main
> corporate focus is still on their compilers.

If Averstar has compilers as their main focus, somebody forgot to tell
their web designer.

Larry Kilgallen

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

[Mark Hertel]

On Thu, 2 Dec 1999 17:37:36 GMT, Larry Kilgallen wrote:
>In article <82638m$cif$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> writes:
>
>> Averstar and ACT are newer, but that really just means that their main
>> corporate focus is still on their compilers.
>
>If Averstar has compilers as their main focus, somebody forgot to tell
>their web designer.

And Averstar absorbed Intermetrics, the company that lost to Groupe
Bull for the original Ada development. They aren't "newer" than
Rational or Aonix.

-- 
Mark Hertel
mnh@thor.com

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

[Robert Dewar]

In article <82638m$cif$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> Averstar and ACT are newer, but that really just means that
> their main corporate focus is still on their compilers.

A peculiar statement :-)

Averstar (Intermetrics) was the runner up in the competition
to define Ada (see the many interesting ideas in the Red
language). They were a major player in both the Ada market and
in the validation effort early on. I will leave it to the
Averstar people to comment on the claim that their main
corporate focus is still on their compilers (that seems quite
wrong to me).

Ada Core Technologies, although new as a company, is hardly new
to the Ada game.

A central core of the company has been working on Ada since
the early 80's (several of the people working for Ada Core
Tecnologies were involved in the 1983 first Ada validation,
and we have validation certificate number 001 hanging on the
wall).

Anyway, the issue is not so much whether a company is focussed
on compilers, but rather whether they are focussed on Ada. At
Ada Core Technologies, our attention is focussed more and more
on tools, rather than the compiler itself, but still very much
focussed on Ada.

Robert Dewar
Ada Core Technologies



Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Richard D Riehle]

In article <82s5qs$ocb$1@nnrp1.deja.com>,
	Robert Dewar <dewar@gnat.com> wrote:

>Anyway, the issue is not so much whether a company is focussed
>on compilers, but rather whether they are focussed on Ada. At
>Ada Core Technologies, our attention is focussed more and more
>on tools, rather than the compiler itself, but still very much
>focussed on Ada.

Hmmmmm.  I wonder how many other companies are still around that are
focused on Ada.  Just as ACT is, so is AdaWorks.  Perhaps ICC, RR
Software, and OCS.  Any others solely devoted to Ada?  

Richard Riehle
http://www.adaworks.com  
 

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

[Marin D. Condic]

Richard D Riehle wrote:
> Hmmmmm.  I wonder how many other companies are still around that are
> focused on Ada.  Just as ACT is, so is AdaWorks.  Perhaps ICC, RR
> Software, and OCS.  Any others solely devoted to Ada?

It would seem to me that it might be beneficial for Ada if a vendor is
*not* focused solely on just the one language. If, for example, someone
were to purchase a C++ compiler that also came with an Ada front end,
then there may be some temptation for the end users to want to tinker
with Ada or perhaps take advantage of some of the software available in
Ada. Granted, the companies that do this generally sell the front ends
as separate options, but at least it is in their advertising literature
and the exposure is thus broadened. Consider the advantage GNAT has in
that it effectively provides the end user with a C compiler as well as
an Ada compiler. Lots of Ada projects still have a need to utilize
*some* amount of C (or other language) code.

MDC
-- 
============================================================================================
                Marin David Condic   - Quadrus Corporation -  
1.800.555.3393
   1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233   - 
http://www.quadruscorp.com/

                      Visit my web site at:  http://www.mcondic.com/
============================================================================================

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

[Marin D. Condic]

Richard D Riehle wrote:
> Hmmmmm.  I wonder how many other companies are still around that are
> focused on Ada.  Just as ACT is, so is AdaWorks.  Perhaps ICC, RR
> Software, and OCS.  Any others solely devoted to Ada?

It would seem to me that it might be beneficial for Ada if a vendor is
*not* focused solely on just the one language. If, for example, someone
were to purchase a C++ compiler that also came with an Ada front end,
then there may be some temptation for the end users to want to tinker
with Ada or perhaps take advantage of some of the software available in
Ada. Granted, the companies that do this generally sell the front ends
as separate options, but at least it is in their advertising literature
and the exposure is thus broadened. Consider the advantage GNAT has in
that it effectively provides the end user with a C compiler as well as
an Ada compiler. Lots of Ada projects still have a need to utilize
*some* amount of C (or other language) code.

MDC
-- 
============================================================================================
                Marin David Condic   - Quadrus Corporation -  
1.800.555.3393
   1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233   - 
http://www.quadruscorp.com/

                      Visit my web site at:  http://www.mcondic.com/
============================================================================================

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

[Marin D. Condic]

Richard D Riehle wrote:
> Hmmmmm.  I wonder how many other companies are still around that are
> focused on Ada.  Just as ACT is, so is AdaWorks.  Perhaps ICC, RR
> Software, and OCS.  Any others solely devoted to Ada?

It would seem to me that it might be beneficial for Ada if a vendor is
*not* focused solely on just the one language. If, for example, someone
were to purchase a C++ compiler that also came with an Ada front end,
then there may be some temptation for the end users to want to tinker
with Ada or perhaps take advantage of some of the software available in
Ada. Granted, the companies that do this generally sell the front ends
as separate options, but at least it is in their advertising literature
and the exposure is thus broadened. Consider the advantage GNAT has in
that it effectively provides the end user with a C compiler as well as
an Ada compiler. Lots of Ada projects still have a need to utilize
*some* amount of C (or other language) code.

MDC
-- 
============================================================================================
                Marin David Condic   - Quadrus Corporation -  
1.800.555.3393
   1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233   - 
http://www.quadruscorp.com/

                      Visit my web site at:  http://www.mcondic.com/
============================================================================================

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

[Marin D. Condic]

Richard D Riehle wrote:
> Hmmmmm.  I wonder how many other companies are still around that are
> focused on Ada.  Just as ACT is, so is AdaWorks.  Perhaps ICC, RR
> Software, and OCS.  Any others solely devoted to Ada?

It would seem to me that it might be beneficial for Ada if a vendor is
*not* focused solely on just the one language. If, for example, someone
were to purchase a C++ compiler that also came with an Ada front end,
then there may be some temptation for the end users to want to tinker
with Ada or perhaps take advantage of some of the software available in
Ada. Granted, the companies that do this generally sell the front ends
as separate options, but at least it is in their advertising literature
and the exposure is thus broadened. Consider the advantage GNAT has in
that it effectively provides the end user with a C compiler as well as
an Ada compiler. Lots of Ada projects still have a need to utilize
*some* amount of C (or other language) code.

MDC
-- 
============================================================================================
                Marin David Condic   - Quadrus Corporation -  
1.800.555.3393
   1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233   - 
http://www.quadruscorp.com/

                      Visit my web site at:  http://www.mcondic.com/
============================================================================================

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

[Simon Wright]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Martin Dowie <martin@dowie-cs.demon.co.uk> writes:

> Apex describe them on their web site -
> "Rational Apex provides a framework for defining architectural
> components, known as Rational Subsystems�. These subsystems
> integrate with the Rational Apex version control system and with Ada
> 95 package hierarchies. Rational Apex prevents undesirable code
> references by controlling visibility among architectural
> components. Attempts to improperly reference units results in
> compile time error messages. In this way, subsystems enable users to
> automatically express and enforce the large-scale structure, or
> architecture, of their applications."

Subsystems may be good for a lot of things, but this particular one
has always struck me as odd; especially in an environment where code
is designed before it's implemented, and inspected afterwards.

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

[jim_snead]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

In article <x7vaenv4vle.fsf@pogner.demon.co.uk>, Simon Wright
<simon@pogner.demon.co.uk> wrote:
> Martin Dowie <martin@dowie-cs.demon.co.uk> writes:
> > Apex describe them on their web site -
> > "Rational Apex provides a framework for defining architectural
> > components, known as Rational Subsystems�. These subsystems
> > integrate with the Rational Apex version control system and with Ad
> > 95 package hierarchies. Rational Apex prevents undesirable code
> > references by controlling visibility among architectural
> > components. Attempts to improperly reference units results in
> > compile time error messages. In this way, subsystems enable
> > automatically express and enforce the large-scale structure, or
> > architecture, of their applications."
> Subsystems may be good for a lot of things, but this particular one
> has always struck me as odd; especially in an environment where
> code is designed before it's implemented, and inspected afterwards.

For an OO design we may have a sea of classes created through
an OO drawing tool. I wonder what leverage Apex adds here.
I sense that they are unsure where the architectural enforcement
should come in to play.

1. Design (OO model)  - Enforce the architecture via a tool like Rose
2. Implementation  - Transcription of design, no enforcement necessary
3. Inspection - Check that transcription was correct

Rose can do the enforcement and Apex can do the enforcement, but
how can Apex enforce something that was not in the original
OO model (such as the notion of visibility control)?  And
if these were in the original model, then they would clearly
map into things like Ada 95 private packages. In which case
you would not need the Apex subsystems to enforce anything!

I do agree with you that it is odd and very confusing when you
consider the early design. Thanks for the insight.




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

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

[Tucker Taft]

jim_snead wrote:
> 
> I have been studying the Rational Apex product
> as an Ada 95 and Java development environment.
> Apex has an unusual feature called "subsystems"
> which to me seems quite useless.

For what it is worth, essentially all Ada compilers have
something analogous to subsystems, typically called "sublibraries"
or "catalogs" or some such thing.  Rational's subsystems do have
more mechanism supporting them.  In most other compilers, a sublibrary
is just another directory with perhaps a specially-named file or two
(e.g. "ada.lib").  The net result is pretty much the same -- you can
do configuration management over a subset of the sources of a large
system, and bundle together the sources that make up a conceptual
"library" of some sort (e.g. a graphics library, a database library,
etc.) for easier reuse across projects.

Rational subsystems add some amount of visibility control, which
doesn't seem as useful as it was in Ada 83, given the ability to
use child units in Ada 95.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

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

[jim_snead]

In article <384450A7.CAF2722F@averstar.com>, Tucker Taft
<stt@averstar.com> wrote:
> jim_snead wrote:
> >
> > I have been studying the Rational Apex product
> > as an Ada 95 and Java development environment.
> > Apex has an unusual feature called "subsystems"
> > which to me seems quite useless.
> For what it is worth, essentially all Ada compilers have
> something analogous to subsystems, typically called "sublibraries"
> or "catalogs" or some such thing.  Rational's subsystems do have
> more mechanism supporting them.  In most other compilers, a
> sublibrary
> is just another directory with perhaps a specially-named file or
> two (e.g. "ada.lib").  The net result is pretty much the same -- you
> can
> do configuration management over a subset of the sources of a large
> system, and bundle together the sources that make up a conceptual
> "library" of some sort (e.g. a graphics library, a database
> library, etc.) for easier reuse across projects.

If this is alluding to the problem of brittle libraries in
Ada 83 code, I can see why someone might be gun-shy of having
a large subsystem. I have heard many stories of "ada.lib"
libraries in the traditional sense that can easily get
out of sync or get corrupted and lead to massive rebuilds.
If you spread ada.lib's around, not as much can get damaged
at once. A clever deceit on Rational's part but I do not buy it.

What I rather do like is the idea of source based libraries.
Apparently more Ada 95 compiler vendors are turning to
source-based libraries, and they have a reputation of being
very stable.
Therefore I conclude that a lighter-weight directory structure
may be more useful for future growth.

Thanks for the hints.

> Rational subsystems add some amount of visibility control, which
> doesn't seem as useful as it was in Ada 83, given the ability to
> use child units in Ada 95.

Agreed

> --
> -Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
> Technical Director, Distributed IT Solutions
> (www.averstar.com/tools)
> AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA



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

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

[Larry Kilgallen]

In article <00844d40.d48fa2f6@usw-ex0107-043.remarq.com>, jim_snead <basswoodNObaSPAM@my-deja.com.invalid> writes:

> If this is alluding to the problem of brittle libraries in
> Ada 83 code, I can see why someone might be gun-shy of having
> a large subsystem. I have heard many stories of "ada.lib"
> libraries in the traditional sense that can easily get
> out of sync or get corrupted and lead to massive rebuilds.
> If you spread ada.lib's around, not as much can get damaged
> at once. A clever deceit on Rational's part but I do not buy it.
> 
> What I rather do like is the idea of source based libraries.
> Apparently more Ada 95 compiler vendors are turning to
> source-based libraries, and they have a reputation of being
> very stable.
> Therefore I conclude that a lighter-weight directory structure
> may be more useful for future growth.

Other merits of various library structures aside, the notion that
Ada implementors should avoid traditional libraries because they
cannot build a reliable one is a sad statement indeed.

"Careful write" strategies can protect a library against operating
system crashes, so I see no excuse why correct library code should
not result when an Ada compiler implementor attempts such a feature.

Larry Kilgallen

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

[Andreas Winckler]

jim_snead wrote:
> 
> I have been studying the Rational Apex product
> as an Ada 95 and Java development environment.
> Apex has an unusual feature called "subsystems"
> which to me seems quite useless.

Recently I made an evaluation whether to make further use of Apex or
other compilers. We have Apex already in use as well as other tools.

Subsystems might be useful for big projects even as they do not really
map to the Rose/UML concepts. But in my opinion Apex suffers much more
from other things:

- poor user interface (no syntax highlighting for example)
- too big, too complicatet for small projects
- it does not really work together well with external tools, CM-tools
other than ClearCase for example
- way too expensive, which gets worse through Rational's licence policy
(one_man_one_licence)

A interesting feature of Apex is the re-compile on statement level, but
I found out that this only compensates that Apex compiles very slow. A
good feature is that you can choose the compiler model which allows to
use code for VADS without any further efforts.

After all we decided that Apex does not fit to our small and mid-size
projects and is much too expensive for us. Besides that we have already
a CM in use which does not really fit together with Apex. Unfortunately
there is no flexible and cheap "Apex-light" which I'd like to see from
Rational.



Greetings,

AW
-- 
---------------------------------------------------------
Andreas Winckler
http://www.talknet.de/~andreas.winckler/
ICQ# : 28867366

"A good plan today is better than a perfect plan tomorrow"

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

[jim_snead]

In article <3844D7DB.BBE53FD9@gmx.de>, Andreas Winckler
<andreas.winckler@gmx.de> wrote:
> A interesting feature of Apex is the re-compile on statement
> level, but
> I found out that this only compensates that Apex compiles very
> slow. A
> good feature is that you can choose the compiler model which
> allows to use code for VADS without any further efforts.

It sounds as if the Apex environment is locked into a single host
environment. So if you go to source code that was set up with a
particular operating system, you cannot modify anything
with another environment (say Solaris versus AIX). This is
extremely contrary to portable Ada or Java development. In many
instances one set of code could work for many different
environments.

I know that with the version control systems such as RCS and CVS,
there is no OS dependence on checking files out.  You can
point at the code and do as you please.



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

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

[Samuel T. Harris]

jim_snead wrote:
> 
> In article <3844D7DB.BBE53FD9@gmx.de>, Andreas Winckler
> <andreas.winckler@gmx.de> wrote:
> > A interesting feature of Apex is the re-compile on statement
> > level, but
> > I found out that this only compensates that Apex compiles very
> > slow. A
> > good feature is that you can choose the compiler model which
> > allows to use code for VADS without any further efforts.
> 
> It sounds as if the Apex environment is locked into a single host
> environment. So if you go to source code that was set up with a
> particular operating system, you cannot modify anything
> with another environment (say Solaris versus AIX). This is
> extremely contrary to portable Ada or Java development. In many
> instances one set of code could work for many different
> environments.
> 

I believe you have mis-read Andreas Winckler. I think Andreas
was refering to the RCI (Remote Compilation Integrator) facility.
This facility has two part to it. The first is the customization
of a very general Ada semantic compiler. This compiler does not
produce any object code, but it does produce the semantic trees
which drive the ASIS stuff as well as the smart editor. The second
part of an RCI is the collection of scripts necessary to control
the actual target compiler. RCI customizations provide extra
"compiler models" as Andreas put it. This allows a project which
has to support several compilers to use the single Apex development
environment for all of them. This does not mean Apex only runs
on a single environment.

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

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

[jim_snead]

In article <3846CB5D.F1F77C21@hso.link.com>, "Samuel T. Harris"
<sam_harris@hso.link.com> wrote:
> jim_snead wrote:
> > It sounds as if the Apex environment is locked into a single host
> > environment. So if you go to source code that was set up with a
> > particular operating system, you cannot modify anything
> > with another environment (say Solaris versus AIX). This is
> > extremely contrary to portable Ada or Java development. In many
> > instances one set of code could work for many different
> > environments.
> I believe you have mis-read Andreas Winckler. I think Andreas
> was refering to the RCI (Remote Compilation Integrator) facility.
> This facility has two part to it. The first is the customization
> of a very general Ada semantic compiler. This compiler does not
> produce any object code, but it does produce the semantic trees
> which drive the ASIS stuff as well as the smart editor. The second
> part of an RCI is the collection of scripts necessary to control
> the actual target compiler. RCI customizations provide extra
> "compiler models" as Andreas put it. This allows a project which
> has to support several compilers to use the single Apex development
> environment for all of them. This does not mean Apex only runs
> on a single environment.

Does this mean that you can set up a source code area that
is compilable to a platform-neutral format such as Java Byte Codes,
and then allow any host to do check-ins and check-outs and building
of semantic trees.  The RCI could then be used as a generic
compilation model to be used across many platforms.

Thanks, the RCI seems a bit complex but is probably the
missing piece that explains the Apex approach.



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

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

[Samuel T. Harris]

jim_snead wrote:
> 
> In article <3846CB5D.F1F77C21@hso.link.com>, "Samuel T. Harris"
> <sam_harris@hso.link.com> wrote:
> > jim_snead wrote:
> > > It sounds as if the Apex environment is locked into a single host
> > > environment. So if you go to source code that was set up with a
> > > particular operating system, you cannot modify anything
> > > with another environment (say Solaris versus AIX). This is
> > > extremely contrary to portable Ada or Java development. In many
> > > instances one set of code could work for many different
> > > environments.
> > I believe you have mis-read Andreas Winckler. I think Andreas
> > was refering to the RCI (Remote Compilation Integrator) facility.
> > This facility has two part to it. The first is the customization
> > of a very general Ada semantic compiler. This compiler does not
> > produce any object code, but it does produce the semantic trees
> > which drive the ASIS stuff as well as the smart editor. The second
> > part of an RCI is the collection of scripts necessary to control
> > the actual target compiler. RCI customizations provide extra
> > "compiler models" as Andreas put it. This allows a project which
> > has to support several compilers to use the single Apex development
> > environment for all of them. This does not mean Apex only runs
> > on a single environment.
> 
> Does this mean that you can set up a source code area that
> is compilable to a platform-neutral format such as Java Byte Codes,
> and then allow any host to do check-ins and check-outs and building
> of semantic trees.  The RCI could then be used as a generic
> compilation model to be used across many platforms.
> 

Since I have customized the RCI to work with Intermetrics
AdaMagic compiler (which generates Java Byte Codes) the
answer to your question is yes. Taking full advantage of
RCI capabilities insures a single development environment
no matter how many target compilers are involved. The only
remaining issue is that developers still have to learn
the debuggers for the target compilers. Howver, there is
much less need to use target debuggers when nearly all
development and testing can be done within Apex itself.

> Thanks, the RCI seems a bit complex but is probably the
> missing piece that explains the Apex approach.
> 
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!

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

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

[Steven Hovater]

Hi Jim

Hmm. We routinely (in Rational) use the multiple-architecture feature of
Apex, as we support five (Solaris, HP-UX, Irix, Digital Unix, Aix) flavors
of Unix.

A user can have an execution file in their $HOME/.Rational directory, which
lists
the machine kind and names. Then, suppose I'm on a Solaris system and
need to compile code on HP-UX. Rather than start up another Apex session,
I can compile in the HP view from Solaris, which starts a command server on
the first HP
machine in my execution file. For all intents and purposes, I'm on Solaris,
but compiling with Apex over on an HP. We can check-in/out/compile debug,
on any flavor Unix. The main caveat is that the machines must have Apex
(of the same version) installed and visible from all participating machines.
Semantic browsing/navigation works across the different platforms, as well.
(That is, the Diana is machine independent, but compiler-version dependent.
Hence the comment about the identical versions..)

This is being used successfully at one of my customer sites.

Likewise, another feature that's related to this is the ability to take a
compilation
and spread it across several machines. (Given Ada rules, your milage may
vary on this feature.)

Cheers,
Steve (just another Rational tech rep...)
--
Steven Hovater
svh@rational.com
Software Engineering Consultant
Phone/fax:781-676-2565/2500
Rational Software
Pager: 888-906-2209
83 Hartwell Ave, Lexington, MA
Amateur radio: AA1YH



jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote in message
news:000b8d9b.a5ff48ae@usw-ex0102-016.remarq.com...
> In article <3846CB5D.F1F77C21@hso.link.com>, "Samuel T. Harris"
> <sam_harris@hso.link.com> wrote:
> > jim_snead wrote:
> > > It sounds as if the Apex environment is locked into a single host
> > > environment. So if you go to source code that was set up with a
> > > particular operating system, you cannot modify anything
> > > with another environment (say Solaris versus AIX). This is
> > > extremely contrary to portable Ada or Java development. In many
> > > instances one set of code could work for many different
> > > environments.
> > I believe you have mis-read Andreas Winckler. I think Andreas
> > was refering to the RCI (Remote Compilation Integrator) facility.
> > This facility has two part to it. The first is the customization
> > of a very general Ada semantic compiler. This compiler does not
> > produce any object code, but it does produce the semantic trees
> > which drive the ASIS stuff as well as the smart editor. The second
> > part of an RCI is the collection of scripts necessary to control
> > the actual target compiler. RCI customizations provide extra
> > "compiler models" as Andreas put it. This allows a project which
> > has to support several compilers to use the single Apex development
> > environment for all of them. This does not mean Apex only runs
> > on a single environment.
>
> Does this mean that you can set up a source code area that
> is compilable to a platform-neutral format such as Java Byte Codes,
> and then allow any host to do check-ins and check-outs and building
> of semantic trees.  The RCI could then be used as a generic
> compilation model to be used across many platforms.
>
> Thanks, the RCI seems a bit complex but is probably the
> missing piece that explains the Apex approach.
>
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>

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

[Andreas Winckler]

jim_snead wrote:
> It sounds as if the Apex environment is locked into a single host
> environment.

No, it's not. Apex is available on many platforms and works well with
plain Ada-code. Unfortunately we have lots of code which makes use of
some VADS-specific things causing problems with other compilers.

> So if you go to source code that was set up with a
> particular operating system, you cannot modify anything
> with another environment (say Solaris versus AIX).

No, that's wrong. As long as you stay strictly with the Ada standard
you're out of trouble.



Greetings,

AW
-- 
---------------------------------------------------------
Andreas Winckler
http://www.talknet.de/~andreas.winckler/
ICQ# : 28867366

"A good plan today is better than a perfect plan tomorrow"

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

[David W. Glessner]

Andreas Winckler wrote:
> ... But in my opinion Apex suffers much more
> from other things:
> 
> - poor user interface (no syntax highlighting for example)

I'm not too fond of Apex's standard editor either.
Fortunately, Apex has an emacs and ada-mode that does
syntax highlighting, along with other niceties like
"Show Usage".

See apexinit's "-emacs" option for more information.

--
David

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

[Tom_Hargraves]

It's all a question of size.

If you have a nice, self-contained, < 100K loc (say),  5 to 10 person job.
Don't bother buying Apex. **
Some smart naming conventions and the ada package is enough to delineate
team/design tasks.
You can also cut corners on configuration control within the team during
development. (only) :-)

If you have a many_person job (we have 200), >1M loc, lots of COTS to link in,
you need something more.
Apex subsystems are used on our project to great advantage, they are tied in to
team structures and the very good Apex configuration control system. The ada
package should be kept reasonably small in size , so on a large project you
have a lot of packages. Subsystems are a way of logically grouping ada packages
in the 'project' sense.***

Regards,
     Tom H.

Notes:
** However, Apex has very good browsing capabilities. Click on a variable and
hit a button called Show Usage and it'll list all the 'readers and writers' of
the variable, and where it was declared etc. Highlight a procedure name and
click Visit and a window pops up with the procedure in it etc. etc. So if
you've got the money, Apex is _really_cool_ for programmers and maintainers
whatever the project size.

*** We are an Ada83 project. Ada 95 may be of help here. However, my brain gets
more and more taxed, the more dots I see in declarations, and 'renames' doesn't
seem to help ;-)









jim_snead <basswoodNObaSPAM@my-deja.com.invalid.rsc.raytheon.com> on 11/26/99
10:50:15 AM

Please respond to comp.lang.ada@ada.eu.org
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      comp.lang.ada@ada.eu.org                            
                                                              
 cc:      (bcc: Tom Hargraves/RMD/Raytheon/CA)                
                                                              
                                                              
                                                              
 Subject: Is Apex dead as an environment for Ada & Java?      
                                                              







I have been studying the Rational Apex product
as an Ada 95 and Java development environment.
Apex has an unusual feature called "subsystems"
which to me seems quite useless.

Apparently the notion is that you can place related
pieces of software into a subsystem, which is a
directory structure with strict naming conventions
(ends with a *.ss which nests other directories).
Other developers can place their own software into
another subsystem as a library.  The "subsystem"
seems to be a legacy organizing feature from
archaic software practices.

For any practical development in Java or Ada 95,
this notion seems particularly baroque and
antiquated.  With Java, the package namespace is the
organizing feature. Even though Rational sells an
Apex for Java, it is beyond me how subsystems would
even begin to work with Java. I guess that one
could put all of an organization's Java source libraries
into a single subsystem. But then what is the point
of a subsystem? In the same way, I believe that Ada
package hierarchies are sufficient to avoid the
need for multiple subsystems.

Why would anyone consider paying money for Apes
when it does not pay any attention to common
Java or Ada 95 deployment philosophies? Or am I
missing something?  (I do not care at all about
C or Ada 83).



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


_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/cgi-bin/mailman/listinfo/comp.lang.ada

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

[jim_snead]

In article <OF58CF2558.4CE834B3-ON88256835.006A3FF1@ray.ca>,
Tom_Hargraves@Raytheon.com wrote:
> *** We are an Ada83 project. Ada 95 may be of help here. However,
> my brain gets
> more and more taxed, the more dots I see in declarations, and
> 'renames' doesn't
> seem to help ;-)

Like I said, I don't care about Ada 83 with respect to Apex.
Apex Subsystems may be a viable option for organizing Ada 83
packages. However subsystems are useless for standard Ada 95.
According to one rationale I saw, the Ada 95 package
hierarchy was introduced as an advancement of the old
Rational R1000 (?) subsystem approach.

My hypothesis is that using a single subsystem and then using
multiple Apex "views" is all that is needed for a large Ada 95 project.
It stands to reason that the concept of a subsystem is therefore
unnecessary and outdated.

Other options are combinations of CVS, emacs, etc as others
have proposed.    These sound much more effective for Ada 95
and Java development.



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

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

[Steven Hovater]

Useless for Ada95? That'll come as a surprise to quite a few of my
customers.

And how do you enforce your architecture? Another of the strengths that Apex
brings is that one can use its subsystems and views to enforce your software
architecture. It's common practice among Apex users to use what are called
"export sets" which allow a user to define the visibility into a view,
thereby
preventing unintended and potentially architecture-breaking dependencies
to be established.

The browsing that Apex does is far beyond what one can get with emacs
(I can't comment on the other environments). One can navigate (based on
Asis)
to object and type definitions that the compiler sees - it's not a
tags-based
paradigm as in other approaches.

Finally, as Tom indicated, for tiny projects, Apex _is_ probably overkill.
BUT -
imagine a single program library and the sheer impracticality of having
mega-lines of source code in a single bucket.

Apex scales.

Disclaimer: I spend 99% of my time working with Apex and Apex embedded
projects
with Rational's customers in the NorthEast.

Regards,
Steve
--
Steven Hovater
svh@rational.com
Software Engineering Consultant
Phone/fax:781-676-2565/2500
Rational Software
Pager: 888-906-2209
83 Hartwell Ave, Lexington, MA
Amateur radio: AA1YH



jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote in message
news:000b8d9b.8e8e4afb@usw-ex0107-042.remarq.com...
> In article <OF58CF2558.4CE834B3-ON88256835.006A3FF1@ray.ca>,
> Tom_Hargraves@Raytheon.com wrote:
> > *** We are an Ada83 project. Ada 95 may be of help here. However,
> > my brain gets
> > more and more taxed, the more dots I see in declarations, and
> > 'renames' doesn't
> > seem to help ;-)
>
> Like I said, I don't care about Ada 83 with respect to Apex.
> Apex Subsystems may be a viable option for organizing Ada 83
> packages. However subsystems are useless for standard Ada 95.
> According to one rationale I saw, the Ada 95 package
> hierarchy was introduced as an advancement of the old
> Rational R1000 (?) subsystem approach.
>
> My hypothesis is that using a single subsystem and then using
> multiple Apex "views" is all that is needed for a large Ada 95 project.
> It stands to reason that the concept of a subsystem is therefore
> unnecessary and outdated.
>
> Other options are combinations of CVS, emacs, etc as others
> have proposed.    These sound much more effective for Ada 95
> and Java development.
>
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>

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

[jim_snead]

In article <l9E%3.2897$tG2.65404@wbnws01.ne.mediaone.net>, "Steven
Hovater" <nh-ho@mediaone.net> wrote:
> Useless for Ada95? That'll come as a surprise to quite a few of my
> customers. And how do you enforce your architecture?
> Another of the strengths that Apex
> brings is that one can use its subsystems and views to enforce
> your software
> architecture. It's common practice among Apex users to use what
> are called
> "export sets" which allow a user to define the visibility into a
> view, thereby
> preventing unintended and potentially architecture-breaking
> dependencies to be established.

I can enforce quite a bit by using private packages. I can
enforce by using separates. Outside of the private, body and
separates, anything publically visible should be fair game.
Otherwise it sounds like a bad Ada 95 design.

And outside of the Ada 95 language, a lot can be done by layering of
packages. This is a common Java approach as well, since
it doesn't have the same language-supported mechanisms..

> The browsing that Apex does is far beyond what one can get with
> emacs

Somebody mentioned that you can get GNAT to work
with emacs effectively.  In any case, I was under the
impression that emacs was the editor included with Apex, so
that this seems to be a weak advantage.

> (I can't comment on the other environments). One can navigate
> (based on Asis)
> to object and type definitions that the compiler sees - it's not a
> tags-based
> paradigm as in other approaches.

From the sound of it, I don't think the GNAT/emacs is tag-based.

> Finally, as Tom indicated, for tiny projects, Apex _is_ probably
> overkill. BUT -
> imagine a single program library and the sheer impracticality of
> having mega-lines of source code in a single bucket.
> Apex scales.

The source would not be in a single bucket, it can
be spread out over multiple subdirectories or whatever
organizational structure is desired.  With capabilities
like symbolic links, this can give an integrator quite
a bit of flexibility.  I still don't get what is so special
about an Apex subsystem.  I do understand the importance
of having "views" and "histories". These enable one
to get the correct versions of source code out of the
RCS repository.

> Disclaimer: I spend 99% of my time working with Apex and Apex
> embedded projects
> with Rational's customers in the NorthEast.
> Regards,
> Steve
> --
> Steven Hovater
> svh@rational.com
> Software Engineering Consultant
> Phone/fax:781-676-2565/2500
> Rational Software
> Pager: 888-906-2209
> 83 Hartwell Ave, Lexington, MA
> Amateur radio: AA1YH



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

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

[Wes Groleau]

I don't get why the presence of the subsystems feature (which doesn't
have to be used) should make an IDE "dead."

That aside, subsystems as Apex defines them are simply a higher level of
partitioning than package hierarchies (or subsystems as defined by Ada
Quality and Style).  

A package has visible items and non-visible items.

The analogous attribute of an Apex subsystem is "exported" and "not
exported."

A package can be with'ed by another package

A subsystem can be imported by another package.

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

[jim_snead]

In article <384FE6DE.7CCF4AF7@ftw.rsc.raytheon.com>, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote:
> A package can be with'ed by another package
> A subsystem can be imported by another package.

This last statement doesn't make any sense and is probably
why I have given up on the notion of understanding
Apex subsystems for Ada 95 nd Java.



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

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

[Robert Dewar]

In article <l9E%3.2897$tG2.65404@wbnws01.ne.mediaone.net>,
  "Steven Hovater" <nh-ho@mediaone.net> wrote:
> The browsing that Apex does is far beyond what one can get
> with emacs (I can't comment on the other environments). One
> can navigate (based on Asis to object and type definitions
> that the compiler sees - it's not tags-based paradigm as in
> other approaches.

That's misleading, the GNAT IDE does indeed use all the
information generated by the compiler, and can do exactly
the same kind of navigation that APEX does. Note that this
is ONLY achieved when GNAT is the compiler used by EMACS,
it is not available when other compilers, e.g. Rational,
are used with EMACS.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Before you buy.

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

[Henrik Delin]

In article <000b8d9b.8e8e4afb@usw-ex0107-042.remarq.com>,
	jim_snead <basswoodNObaSPAM@my-deja.com.invalid> writes:

> My hypothesis is that using a single subsystem and then using
> multiple Apex "views" is all that is needed for a large Ada 95 project.
> It stands to reason that the concept of a subsystem is therefore
> unnecessary and outdated.

It is not the way it is intended. The views in a subsystem should be seen
as different views of the same bunch of code. Therefore it is not
possible to import views in the same subsystem. This would propably lead
to name clashes, since the same packages usually exist in both views.

A subsystem is a grouping that is the smallest part of an application
that can independently be frozen for releases. It gives a consistent way
of grouping Ada packages in larger groups, and keeping track of releases
of these groups of packages, especially when there are different versions.

/Henrik Delin

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

[Ed Falis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On 26 Nov 1999 21:41:45 GMT, "Pascal Obry" <pascal_obry@csi.com> wrote:
> 
> 
> Tom_Hargraves@Raytheon.com a �crit dans l'article
> <OF58CF2558.4CE834B3-ON88256835.006A3FF1@ray.ca>...
> > 
> > 
> > Notes:
> > ** However, Apex has very good browsing capabilities. Click on a variable
> and
> > hit a button called Show Usage and it'll list all the 'readers and
> writers' of
> > the variable, and where it was declared etc. Highlight a procedure name
> and
> > click Visit and a window pops up with the procedure in it etc. etc. So if
> > you've got the money, Apex is _really_cool_ for programmers and
> maintainers
> > whatever the project size.
> 
> Just a note to say that GNAT+EMACS has all these features... 


As does ObjectAda.

- Ed

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

[jim_snead]

Another failing of the Apex subsystem notion
is how it does not fit into the other Rational product
called Rose UML.   For example, given a brand new
software project I presume one could create an object
oriented model of the Ada software using Rose UML.
Rational advertises that the UML can code generate into
Ada or Java.

So here is another question to continue the thread.
How do you create an object oriented model which
spans Apex subsystems and is written using
Rational Rose UML?

Since the UML is one monolithic model, then the
generated Ada or Java must also fit into one subsystem.
If this is not the case, you risk creating a huge inverted
pyramid in your deployed design. The UML apex at the bottom
essentially supports a fan-out of subsystems, which is clearly
a maintenance nightmare.





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

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

[Steven Hovater]

Hi again Jim

Eh? Think packages in UML as containers. These can map to subsystems+views
in Apex.  (Nested packages map to subdirectories in the subsystem's
views).

Rose Ada lives. NT and Unix. Interfaces to Apex and Apex NT.

Sorry, I don't understand your comment about UML being a "monolithic
model". UML is a language. A Rose model can and is expected to have
a strong software architectural basis - as represented by the UML package,
their relationships, etc.

Cheers,
Steve (just another Rational tech rep)
--
Steven Hovater
svh@rational.com
Software Engineering Consultant
Phone/fax:781-676-2565/2500
Rational Software
Pager: 888-906-2209
83 Hartwell Ave, Lexington, MA
Amateur radio: AA1YH



jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote in message
news:000b8d9b.b5931d11@usw-ex0102-014.remarq.com...
> Another failing of the Apex subsystem notion
> is how it does not fit into the other Rational product
> called Rose UML.   For example, given a brand new
> software project I presume one could create an object
> oriented model of the Ada software using Rose UML.
> Rational advertises that the UML can code generate into
> Ada or Java.
>
> So here is another question to continue the thread.
> How do you create an object oriented model which
> spans Apex subsystems and is written using
> Rational Rose UML?
>
> Since the UML is one monolithic model, then the
> generated Ada or Java must also fit into one subsystem.
> If this is not the case, you risk creating a huge inverted
> pyramid in your deployed design. The UML apex at the bottom
> essentially supports a fan-out of subsystems, which is clearly
> a maintenance nightmare.
>
>
>
>
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network
*
> The fastest and easiest way to search and participate in Usenet - Free!
>