|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.