iSeries Projects... we're listening

Ok, so let me try to gather all your feedback about iSeries Projects here,
but first, I will just make a few comments/answers.

* In response to one of the postings, by no means are we trying to dictate
how a developer might go about doing his task. Users should have very little
learning curve migrating to a new tool. If we have not made that easy, then
we want your feedback.

* The design behind iSeries projects is that there is a one to one mapping
between a project and an iSeries library. Now before I jump and say that we
can certainly change that in furure releases, let me try to give some
background behind it. The idea was that your development task at hand can be
organized in one library. Now that does not mean that you can't verify or
build against other common libraries. It only means that members that you
need to modify will be grouped and pushed to that one library. It is a
scratch library where you will test these changes. "You grab from anywhere,
but your push and test to one place". Out of the box, iSeries projects come
with two build styles. The Command build style will invoke (in batch)
whatever "string" you have configured in that build style. (Click on build
properties of a project to see/configure build styles). This build style is
ideal if you simply want to invoke an existing build sript on the host that
knows how to build your changes. The second build style is the CL build
style that will generate a COMPILLE.CLLE member that will be compiled into a
program which in turn will be run by the build style to compile your code.
Like Violaine mentioned, nothing to stop you from turning off autogeneration
before a "Submit Build" command, and manually modifying this build script.
Now back to the initial point, why one library? It is expected that SCM
vendors will override these build styles. They are designed to be pluggable,
and SCM vendors can provide their own plugins that provide a lot more build
and push functionality. For example, SCMs can provide the typical "promote"
actions that will push all your members back to their initial libraries or
test or production libraries. They will recompile dependencies on the host
that need to be recompiled because of your changes.

* With that said, you might be saying, well I dont have/use SCM tools, I
want to mange my changes myself. Well, in that case, if you have changes in
multiple libraries, you have to create one iSeries project per library. This
way when you perform a push, you will be pushing your changes back to the
original library the member come from. Configure one project to do your
"master" build, but you have to manually make sure that you perform a push
from each project that you modify code in.
Hint: to quickly create an iSeries project for a member that you need to
edit offline, in RSE you can right click on a member or srcpf and select
"Make available offline". That will create an iSeries project with the same
connection and library that the member came from.

* Another point, if you simply need a quick "edit in place" scenario, then
RSE is your ideal solution, if you dont mind the live connection.


Now we want your feedback. For future releases, we certainly can support
multiple libraries. This can be done either using project references or
using one to many mapping of project to libraries. What does that mean to
the user? In the case of project refernces, the one to one mapping is still
in effect, but you can specify that a given iSeries projects has references
or depends on another iSeries Project. Build and push would both honor these
refernces and use them more extensively. In the case of changing the mapping
to be "one project can map to many libraries", the tree viewer would have to
visually display multiple libraries and a push action pushes to various
libraries. Project references may or may not be used in that case.

Besides somehow supporting multiple libraries, please feel free to give us
more feedback that you see might enhance your development cycle using
iSeries projects.


Mazen Faraj
iSeries Projects development, WDSC
Toronto Lab.