* Rational Apex @ 1998-08-05 0:00 Glenn 1998-08-05 0:00 ` David Weller 1998-08-08 0:00 ` Chris Warwick 0 siblings, 2 replies; 12+ messages in thread From: Glenn @ 1998-08-05 0:00 UTC (permalink / raw) Hello... Does anyone have any experiences using Rational Apex with an existing "legacy" project? We are looking into transitioning from VADS to Apex (VADS support will be discontinued for the platform we are using) and I am concerned that our current processes (CM, etc.) will not work with Apex' highly integrated environment. Any info would be appreciated...thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 Rational Apex Glenn @ 1998-08-05 0:00 ` David Weller 1998-08-05 0:00 ` Christopher Green 1998-08-14 0:00 ` Samuel T. Harris 1998-08-08 0:00 ` Chris Warwick 1 sibling, 2 replies; 12+ messages in thread From: David Weller @ 1998-08-05 0:00 UTC (permalink / raw) In article <6q8ab6$3dg$1@newnews.startext.net>, Glenn <gdiehl@startext.net.nospam> wrote: >Any info would be appreciated...thanks. > Nothing really forces you to use Apex. You can still use the compiler from the command line and (I think) library management can be done from the command line. If you have a well-established development process, you should NEVER change it if it is working for you. Even if you current compiler vendor says you have to. Tell them that choice is unacceptable. You would probably find it MUCH cheaper to switch to GNAT if your platform is supported. -- DVD vs. DIVX: The Truth Is Out There => http://www.riva.com/dvd_divx.html ---------------------Read about "Reformed English"---------------------------- "Linguistically ingenious, politically incorrect" http://www.riva.com/re ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 ` David Weller @ 1998-08-05 0:00 ` Christopher Green 1998-08-05 0:00 ` Roy Grimm 1998-08-06 0:00 ` Matthew Heaney 1998-08-14 0:00 ` Samuel T. Harris 1 sibling, 2 replies; 12+ messages in thread From: Christopher Green @ 1998-08-05 0:00 UTC (permalink / raw) In article <6q9qi3$98n@universe.digex.net>, David Weller <dweller@universe.digex.net> wrote: >In article <6q8ab6$3dg$1@newnews.startext.net>, >Glenn <gdiehl@startext.net.nospam> wrote: >>Any info would be appreciated...thanks. >> >Nothing really forces you to use Apex. You can still use the compiler >from the command line and (I think) library management can be done >from the command line. If you have a well-established development >process, you should NEVER change it if it is working for you. Even if >you current compiler vendor says you have to. Tell them that choice >is unacceptable. You would probably find it MUCH cheaper to switch to >GNAT if your platform is supported. Apex is not just a compiler; it's a way of life. Apex has its own highly structured way of doing things. It is insistent about using its own directory structure and file naming conventions, at a minimum. It will reformat your code according to its defaults, unless you force it not to. It has its own CM subsystem (Summit) built in. Apex can be run from the command line, but this does not reduce the need to organize your code into Apex subsystems and views, and at least to observe Apex file naming conventions. Basically, Apex is a heavyweight solution to many of the problems that arise in developing software on a very large scale. But you need to use Apex the way Rational designed it; if you try to impose your own way of doing things on Apex, you will spend all your time fighting it rather than getting work done. -- Chris Green Email cgreen@atc.com Advanced Technology Center Phone (949) 583-9119 22982 Mill Creek Drive ext. 220 Laguna Hills, CA 92653 Fax (949) 583-9213 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 ` Christopher Green @ 1998-08-05 0:00 ` Roy Grimm 1998-08-07 0:00 ` Lowe Anthony A 1998-08-06 0:00 ` Matthew Heaney 1 sibling, 1 reply; 12+ messages in thread From: Roy Grimm @ 1998-08-05 0:00 UTC (permalink / raw) Christopher Green wrote: > > Apex is not just a compiler; it's a way of life. So true. > Apex has its own highly structured way of doing things. It is insistent > about using its own directory structure and file naming conventions, at > a minimum. It will reformat your code according to its defaults, unless > you force it not to. It has its own CM subsystem (Summit) built in. I'm assuming you mean Change Management instead of Configuration Management. Summit is available as one of the many layered products. However, you don't have to use it to track changes You're free to use your old tools. In many of our legacy projects, we still use our old Change Reporting tools instead of Summit. > Apex can be run from the command line, but this does not reduce the need > to organize your code into Apex subsystems and views, and at least to > observe Apex file naming conventions. But this isn't necessarily a bad thing. Getting used to their structure of subsystem/views with multiple history CMVC takes a while, but adds a layer of organization that makes managing large projects significantly easier. Our department makes a reusable bootstrap loader and software loader that is compiled to several different processors. With Apex, we assign different version history trees to critical configuration files, make the rest of the code reference those specific packages. When we make a change to one high level package, it's a few mouse clicks and we've updated every other platform we want to. Very slick, very easy. I'll never miss the old Unix/SCCS days, or that brief stint with WindozeNT and Micro$oft Visiual Source Save... *shudder* > Basically, Apex is a heavyweight solution to many of the problems that > arise in developing software on a very large scale. But you need to use > Apex the way Rational designed it; if you try to impose your own way of > doing things on Apex, you will spend all your time fighting it rather > than getting work done. That's half true. Apex has it's way of doing things. One of those ways is providing the flexibility to manage your project with their tools or someone else's. The basic file and directory structure is provided for you. Everything else is configurable. Don't want to use Rational Rose for documentation? Don't. Want to use another compiler? The Apex IDE has the Remote Compilation Interface that lets you run any third party compiler you want. Hell, I've worked on Apex running on a Sun workstation that remotely compiles on a VAX/VMS workstation. A little set up for the 'rsh' and NFS interface and you're good to go. It's all automatic from within the IDE. Just hit "link" and away it goes. If you've got just one line of products on one target architecture, Apex might be overkill. If you've got dozens of projects with several different projects and requirements to support legacy compilers and what not, Apex is the way to go. -- Roy A. Grimm | Tel: (319)295-8099 Rockwell Collins, Inc. | Fax: (319)295-8940 Cedar Rapids, Iowa | email: ragrimm@collins.rockwell.com When you think how well basic appliances work, it's hard to believe anyone ever gets on an airplane. --Calvin My opinions don't necessarily match those of my employer. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 ` Roy Grimm @ 1998-08-07 0:00 ` Lowe Anthony A 1998-08-11 0:00 ` Gene Ouye 0 siblings, 1 reply; 12+ messages in thread From: Lowe Anthony A @ 1998-08-07 0:00 UTC (permalink / raw) Roy is totally right. For the standard everyday user I equate Apex as driving a circus train to get to work. There can be a ton of overhead just to get the first file put in and compiled. When it comes to the build manager, QA, CCB members, Apex is their best friend. It has quite a few very useful tools and utilities available, but if you are used to a MS interface, it can be quite annoying. As for suggestions/ recommendations: * Learn as much about the Apex tools and how the components function (i.e. subsystem versus view versus history). If you architect correctly, it can be years of easy sailing. If you just throw something together, you will spend more time fighting the tool than building with it. (Another fact true of Ada). * Provide the correct training to the specific job functions. The standard developer needs to have a basic understanding of how Apex does stuff, but does not need gory details about the underbelly of the program. Spend the money however to get the development environment people up to speed on how to manage Apex. This will save much time, dollars, and frustration in the long run. * The RCI capability Roy spoke of is beautiful for replacing 'obsolete' environments with a nice push button GUI. We have quite extensively used a RCI to replace a VAX command line environment and it is immensely helpful. If you choose to use a GUI compiler (GNAT, ObjectAda) the utility of the RCI dramatically drops, since the GUI environments provided by the other compiler are most often easier to use than Apex. * Overall, like Roy said, Apex is a great tool if you need strong Configuration Management, Change Management, and have a very diverse or changing product. I find it quite cumbersome to use as just a coding environment (especially if you have PC's in front of the developers and they have to XWindow over to a server to use it!). If you have a simple product, I would think hard about a smaller product. Good Luck! -- Tony Lowe Rockwell Collins 1431 Opus Place - Downers Grove, IL 60515 (630)-960-8603 Fax : (630)-960-8207 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-07 0:00 ` Lowe Anthony A @ 1998-08-11 0:00 ` Gene Ouye 0 siblings, 0 replies; 12+ messages in thread From: Gene Ouye @ 1998-08-11 0:00 UTC (permalink / raw) !!!!!!!!!!! WARNING !!!!!!!!!!! !!! SHAMELESS PLUG INCLUDED !!! !!!!!!!!!!! WARNING !!!!!!!!!!! I agree with most of the things that Tony said below especially his first three "suggestions/recommendations", but I do have to comment on some of his post (I must warn you that I work for Rational and am directly associated with the product discussed in the next few paragraphs, so you should consider my opinions biased, even if they are true :-) First, I've missed most of the start of this thread, so I apologize in advance for any duplication or wasted bandwidth... I can understand the metaphor comparing Apex for the "everyday user" with every day commuting in a rather large, cumbersome, vehicle, but "circus train" wouldn't be my first choice! ;-) One could argue whether that metaphor is appropriate, but I would rather discuss another option that isn't mentioned: Apex Ada for Windows NT. If you have a bunch of PC's sitting on your desktops, and they are capable of running NT4.0, then you can run Apex Ada natively on the PCs instead of using them as X-servers connected to UNIX boxes. You can get it without all the "cumbersome" :-( features like Configuration Management and Change Management if you like. Most people who use it comment favorably on how un-"cumbersome" it really is. There's no need to use an X-server to UNIX, it's a Windows application, and in fact it comes with a demo version of CLAW and the CLAW GUI builder. If you want to work in conjunction with existing UNIX Apex developers, you can easily plug Apex NT into the UNIX CMVC repository. There are some things you will not get away from. The subsystem/view paradigm is still there in Apex NT even if you choose not to use CMVC (in fact, it maps nicely to DLLs). And the whole notion of imports and exports between Rational subsystems is an extremely powerful paradigm for architecting an application. Also, Apex NT (like UNIX Apex and like GNAT) requires one compilation unit per file, and the filename is directly related to the unit name (although not in the same way as GNAT). And yes, there is a straightforward way (incorporated into the GUI) to parse the compilation units out of other source files :-) I do a lot of simple Ada things these days (I'm in a marketing job now, need I say more?) and I find it quite easy to do them with Apex. Just as Ada doesn't force you to create a new integer type for every number in your application (you can make them all Standard.Integer if you want) and Ada doesn't force you to put every tagged type into a different package (you can put your entire application in one procedure if you like), Apex doesn't force you to partition your application into lots of subsystems and views. I keep a "play area" subsystem with a view containing several directories that imports all the base libraries. Whenever I want to throw something together quickly (like when I want to see if someone's sample code really does produce the errors they post), I just go there and try things out. I find the syntactic and semantic completion make writing the simple applications go much faster... BTW, I haven't updated the external Rational web pages with the latest information on Apex NT (didn't want to be pushing vaporware), so don't go rushing over there yet for more details. If you check it over the next few weeks you'll see some pages specifically dedicated to Apex NT. Gene Ouye <g.e.n.e.o.@.r.a.t.i.o.n.a.l...c.o.m> (make the obvious fix to send me mail) Apex Ada NT Product Manager Lowe Anthony A wrote: > > Roy is totally right. For the standard everyday user I equate Apex as > driving a circus train to get to work. There can be a ton of overhead just > to get the first file put in and compiled. When it comes to the build > manager, QA, CCB members, Apex is their best friend. It has quite a few very > useful tools and utilities available, but if you are used to a MS interface, > it can be quite annoying. > > As for suggestions/ recommendations: > * Learn as much about the Apex tools and how the components function (i.e. > subsystem versus view versus history). If you architect correctly, it can be > years of easy sailing. If you just throw something together, you will spend > more time fighting the tool than building with it. (Another fact true of > Ada). > > * Provide the correct training to the specific job functions. The > standard developer needs to have a basic understanding of how Apex does stuff, > but does not need gory details about the underbelly of the program. Spend > the money however to get the development environment people up to speed on how > to manage Apex. This will save much time, dollars, and frustration in the > long run. > > * The RCI capability Roy spoke of is beautiful for replacing 'obsolete' > environments with a nice push button GUI. We have quite extensively used a > RCI to replace a VAX command line environment and it is immensely helpful. > If you choose to use a GUI compiler (GNAT, ObjectAda) the utility of the RCI > dramatically drops, since the GUI environments provided by the other compiler > are most often easier to use than Apex. > > * Overall, like Roy said, Apex is a great tool if you need strong > Configuration Management, Change Management, and have a very diverse or > changing product. I find it quite cumbersome to use as just a coding > environment (especially if you have PC's in front of the developers and they > have to XWindow over to a server to use it!). If you have a simple product, > I would think hard about a smaller product. > > Good Luck! > > -- > Tony Lowe Rockwell Collins > 1431 Opus Place - Downers Grove, IL 60515 > (630)-960-8603 Fax : (630)-960-8207 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 ` Christopher Green 1998-08-05 0:00 ` Roy Grimm @ 1998-08-06 0:00 ` Matthew Heaney 1 sibling, 0 replies; 12+ messages in thread From: Matthew Heaney @ 1998-08-06 0:00 UTC (permalink / raw) cgreen@yosemite.atc.com (Christopher Green) writes: > Apex is not just a compiler; it's a way of life. I think the same thing about emacs. [snip] > Basically, Apex is a heavyweight solution to many of the problems that > arise in developing software on a very large scale. But you need to use > Apex the way Rational designed it; if you try to impose your own way of > doing things on Apex, you will spend all your time fighting it rather > than getting work done. Funny, this is what I often say to programmers about Ada. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 ` David Weller 1998-08-05 0:00 ` Christopher Green @ 1998-08-14 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 12+ messages in thread From: Samuel T. Harris @ 1998-08-14 0:00 UTC (permalink / raw) David Weller wrote: > > In article <6q8ab6$3dg$1@newnews.startext.net>, > Glenn <gdiehl@startext.net.nospam> wrote: > >Any info would be appreciated...thanks. > > > Nothing really forces you to use Apex. You can still use the compiler > from the command line and (I think) library management can be done > from the command line. If you have a well-established development > process, you should NEVER change it if it is working for you. Even if > you current compiler vendor says you have to. Tell them that choice > is unacceptable. You would probably find it MUCH cheaper to switch to > GNAT if your platform is supported. > > -- I've just returned from vacation and missed the original post so please forgive any assumptions I may make below. As an old Apex (and Rational R1000) hack _and_ an avid GNAT user I'd like to add that all library, compilation, and configuration management operations in Apex can indeed be performed in a batch/ command-line mode. Not knowning the original situation, I'll just say that _if_ one is using Apex exclusively in this way, then one is paying WAY too much money supporting the tool. The language sensitive editor and high degree of integration of the GUI elements IS the productivity leverage which justifies the cost of the tool. Other combinations of other tools (such as GNAT + CVS + EMACS) come close and are much cheaper to buy (but require somewhat more sweat to keep running). -- Samuel T. Harris, Principal Engineer Raytheon Training Incorporated "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-05 0:00 Rational Apex Glenn 1998-08-05 0:00 ` David Weller @ 1998-08-08 0:00 ` Chris Warwick 1998-08-09 0:00 ` Corey Ashford 1 sibling, 1 reply; 12+ messages in thread From: Chris Warwick @ 1998-08-08 0:00 UTC (permalink / raw) In article <6q8ab6$3dg$1@newnews.startext.net>, "Glenn" <gdiehl@startext.net.nospam> wrote: >Hello... > >Does anyone have any experiences using Rational Apex with an existing >"legacy" project? We are looking into transitioning from VADS to Apex (VADS >support will be discontinued for the platform we are using) and I am >concerned that our current processes (CM, etc.) will not work with Apex' >highly integrated environment. I find the concept of VADS support being discontinued, and Apex being the replacement. The VADS compiler is at the root of the Apex environment... I ran into this on the Sun where our upgrade after Rational bought VADS starting the Sun code under Apex acting like the VADS code under SCO (this was a good thing as we try to do as much work as possible on the Sun before going to SCO, and the differences were causing a few gotchas). Apex is a small horde of 'C' shell scripts with a GUI on top, so you should have no problem customizing the enviroment to your current procedures. The things that take getting used to are the directory structure required by Apex, and the CM system. The CM system is odd because they copy files rather than creating links so your developers have the impression that they have a local copy of all the files, whereas Apex thinks you only have instances of the files... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-08 0:00 ` Chris Warwick @ 1998-08-09 0:00 ` Corey Ashford 0 siblings, 0 replies; 12+ messages in thread From: Corey Ashford @ 1998-08-09 0:00 UTC (permalink / raw) Chris Warwick wrote in message <6qlci2$da7@priv-sys04-le0.telusplanet.net>... >In article <6q8ab6$3dg$1@newnews.startext.net>, "Glenn" <gdiehl@startext.net.nospam> wrote: >>Hello... >> >>Does anyone have any experiences using Rational Apex with an existing >>"legacy" project? We are looking into transitioning from VADS to Apex (VADS >>support will be discontinued for the platform we are using) and I am >>concerned that our current processes (CM, etc.) will not work with Apex' >>highly integrated environment. > >I find the concept of VADS support being discontinued, and Apex being the >replacement. The VADS compiler is at the root of the Apex environment... I ran >into this on the Sun where our upgrade after Rational bought VADS starting the >Sun code under Apex acting like the VADS code under SCO (this was a good >thing as we try to do as much work as possible on the Sun before going to >SCO, and the differences were causing a few gotchas). This isn't true, exactly. The original VADS Ada front-end went away, replaced by the Apex Ada front-end. IMHO, the best feature of the Apex Ada front-end is the fast-path recompilation. It's very cool, and saves an incredible amount of time particularly when altering package specs which are on the transitive 'with' closure of many packages. What is retained from VADS is the optimizer, code generator, and much of the runtime system. The runtime system has undergone many changes since VADS because of the need for Ada95 support. > >Apex is a small horde of 'C' shell scripts with a GUI on top, so you should >have no problem customizing the enviroment to your current procedures. Many of the scripts are "Apex_Shell" scripts. This is a scripting language that is similar to C shell, but much more powerful, and has many convenient and useful hooks into Apex. >The things that take getting used to are the directory structure required by >Apex, and the CM system. The CM system is odd because they copy files rather >than creating links so your developers have the impression that they have a >local copy of all the files, whereas Apex thinks you only have instances of >the files... This is true, but Apex makes it look as if the files are not simply copies. To alter a file, you must check it out (if it was controlled, which is not required). There are two possible CM systems that can be used in the latest release of Apex... the original Apex Summit CMVC system, and the newer ClearCase CM (which was originally a product of PureAtria, before the two companies merged). - Corey ^ permalink raw reply [flat|nested] 12+ messages in thread
* Rational Apex @ 1998-08-20 0:00 James Amendolagine 1998-08-27 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 12+ messages in thread From: James Amendolagine @ 1998-08-20 0:00 UTC (permalink / raw) I am trying to learn how to use the rational apex environment and am having problems with imports. I am trying to import two views from one subsystem into a view from another. Apex is complaining and rejecting the import of more than wone view. Is there a way to import more than one view? Jamie ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Rational Apex 1998-08-20 0:00 James Amendolagine @ 1998-08-27 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 12+ messages in thread From: Samuel T. Harris @ 1998-08-27 0:00 UTC (permalink / raw) James Amendolagine wrote: > > I am trying to learn how to use the rational apex > environment and am having problems with imports. I am > trying to import two views from one subsystem into a > view from another. Apex is complaining and rejecting > the import of more than wone view. Is there a way to > import more than one view? > > Jamie Each Apex view serve dual roles as a configuration management collective and Ada compilation library mechanism. An Apex subsystem is intended to contain related code upon which some level of component testing can be performed. Configuration management information is contained within the Apex subsystem. An Apex view is a "slice" of the subsystem's configuration management database, selecting at most one version of each controlled object in the subsystem. A subsystem usually contains several views. These views usually include different versions of each controlled object. From this perspective, a view provides the "configuration" in configuration management. A view is also an Apex Ada library. In order to compile units in a view which require (or with) units from another view, some relationship between the two views must be defined. This is view imports. From a compilation perspective, an Apex view is an Ada library. Putting the two perspectives together, it is natural to limit view imports to at most one view from each Apex subsystem. Remember, from the configuration management viewpoint, two views from the same subsystem are two distinct sets of versions of common controlled objects. If you are trying to import two views from the same subsystem which contain the same objects (albeit with different versions) then you have a real problem with usage since this makes no sense from a configuration management perspective. In my experience, it is a common mistake for Apex neophites to ignore the configuration management aspects and simply start off using Apex for the nice language sensitive editor. In such circumstances, is seems obvious to simply define an Apex subsystem for each programmer and define a view for each system component each programmer works on. While this provides all the Apex Ada libraries you need, mixing multiple component views in the same subsystem is violating the underlying princple of Apex subsystems and make this usage vulnerable to configuration management problems when it comes time to integrate components together. When this occurs, multiple views from a single subsystem need to be imported (because each view has a different component) which is not allowed by Apex. After this event, substantial Apex subsystem reorganization occurs resulting in an Apex subsystem for each component each containing a view for each programmer working on the component. If you fall into this category then you will need to reorganize your subsystems so each contains a single set of code _or_ include all code in all views of a subsystem into each view of that subsystem (this is not my first choice). Just as analysis preceeds design which preceeds coding, so should some thought to configuration management be given before laying down tools and libraries. -- Samuel T. Harris, Principal Engineer Raytheon Training Incorporated "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1998-08-27 0:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-08-05 0:00 Rational Apex Glenn 1998-08-05 0:00 ` David Weller 1998-08-05 0:00 ` Christopher Green 1998-08-05 0:00 ` Roy Grimm 1998-08-07 0:00 ` Lowe Anthony A 1998-08-11 0:00 ` Gene Ouye 1998-08-06 0:00 ` Matthew Heaney 1998-08-14 0:00 ` Samuel T. Harris 1998-08-08 0:00 ` Chris Warwick 1998-08-09 0:00 ` Corey Ashford -- strict thread matches above, loose matches on Subject: below -- 1998-08-20 0:00 James Amendolagine 1998-08-27 0:00 ` Samuel T. Harris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox