|
midrange.com
Let me see if I can clarify a few things...
1) There can only be ONE Associated library each project. BUT you can have
several projects with the same associated library.
2) When a project does a build, the *CURLIB is changed to the associated
library.
3) When you select the "show remote objects" function in a project, only
the objects in the assoc. library are displayed.
4) A user can use the project "import" function or the RSE "Add to iSeries
project" to add source to a library
5) Push will ONLY send members to the associated library
6) The CL build style automatically generates a CL member in the project
which (using RSE compile defaults) generates CL source that would build
the project. In most cases, the user would need to modify such a generated
script. Once a user modifies this script, he or she should be careful not
request that the project regenerate the script :-) by selecting the
Generate compile code.
7) If there already is a build program you call on the host, use the
command build style, and specify the command that does your build.
8) If you have /COPY (etc) in other projects, you can use the project
reference section in the project properties to ensure that the verify
function finds the project copy (rather than the host copy). Note that
project references only impact verify right now and not build.
9) There is nothing that stops a user who is using either build style, to
build objects in libraries not in the associated libraries. However, as
project references have no impact on build, the user would have to make
sure that all changes for all projects are pushed, prior to submitting a
build.
10) iSeries Projects are not meant to replace change management tools.
There is some simple conflict detection (much like in CODE), but the
original design is such that projects should be used in conjunction with
CMTs, which generally require a user to "check out" parts/members to a
specific user library for development purposes.
Violaine Batthish
CODE Project Lead
batthish@xxxxxxxxxx
Vern Hamberg
<vhamberg@xxxxxxxxxxxxxxx To: Websphere
Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
nology.com> cc:
Sent by: Subject: RE: [WDSCI-L]
Re: iSeries Project
wdsci-l-bounces@xxxxxxxxx
com
06/06/2003 01:09 AM
Please respond to
Websphere Development
Studio Client for iSeries
Mark, you've given me stuff to think about. I'll be taking another look.
Someone once said (Violaine? Phil C.?) that the project is not a
full-fledged change management tool. It looks as if you all are able to
take good advantage of it in your product, however.
Consider this scenario -
1. our header files in the same library as C source, both for common
objects and product-specific objects
2. different libraries for the common and product stuff
3. target library for objects is separate from either of these other 2,
except modules
- modules usually in one of the source libraries - not distributed
4. a build program that establishes a compilation environment (lib list,
etc.) and creates all the objects
So, does a project allow you to specify a build program? is this like your
"wizard" or "style"? Does this program run in the "associated" library? Are
these wizards part of TurnOver or of WDSC?
Later
Vern
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
