Adding a BLDRELIC CLP to the Relic Package Manager

We have previously shown how to interact with GitHub and RDi for IBM i Open Source projects. This blog entry is another step in the learning cycle. Its trivial in its content but the process we are following can be used in larger projects as we move forward. 

One of the problems with Relic Package Manager is the manual steps required to create the objects, these are required for other Open Source projects that are built with its use in mind. Liam does provide a build.txt file which has the steps required to build the objects, but that would normally be run through the Relic Package Manager process, we don’t have the objects yet so this is the proverbial catch22.

The CLP we are going to add will eventually form part of the downloadable source, all you have to do once this is available is compile the CLP into the source library and run it. It will build the #RELIC library (we allow a different name to be used but lets stick with whats been done so far) and create all of the objects required in that library. Relic Package Manager only contains a few objects at this stage, so the benefit we get from adding the CLP is not going to be huge, but it will be another learning experience for using RDi and Git on an Open Source project. The more we practice the better we become at building our own projects and contributing to others using the tools we have.

If you want to get the starting objects you can following the previous Blog entry which shows how to get the source code for Relic Package Manager to your PC and connected IBM i using RDi and Git.

Open the workspace in RDi and ensure you have the IBM i project perspective open and the Git Perspective Open. We will use both of these as part of the exercise.

In the IBM i Project view add a new member to the QSOURCE file called BLDRELIC.

Add new member in Project view

Add new member in Project view

 

File member details

File member details


Open up the build.txt file from within the Git perspective. Note they are on the top right of the tool bar.

build.txt content

build.txt content

Switch back to the IBM i project perspective. We are going to copy the relevant commands from the build.txt file to the BLDRELIC source member. But first of all let’s add some content to the CLP to get us going. The objects we create may be used across any number of systems and OS levels so we will take 3 parameters into the program (SRCLIB, OBJLIB, TGTRLS). Then copy the lines which compile the objects from the build.txt file and adjust the commands to reflect the parms we are taking into the program.

BLDRELIC CLP content

BLDRELIC CLP content

Now we can compile the object into the Source lib to make sure it compiles and test that it creates the objects required.

Compile BLDRELIC.CLP

Compile BLDRELIC.CLP

We opted to use the IBM i project perspective, you could also use the Remote Explorer perspective once you have pushed the new object to the IBM i. As mentioned before RDi does manage the source copy to the IBM i from the PC as it did in this case once we submitted the compile request. It only exists on the PC when adding the code and saving the object.

We checked the IBM i just to make sure the compile had completed (for some reason the messages in the IBM i Project perspective are not as good as those in the RSE perspective. Another RFE?).

BLDRELIC Program successfully built

BLDRELIC Program successfully built


Now we can call the program passing in the parameters we want and the objects are built in the library of our choice.

Objects now built and ready to use.

Objects now built and ready to use.


If we want to share our updates with the community (and you really should) we need to update the target repository so that others can download the source we have just created. We removed the sequence numbers and dates to ensure it follows the same source layouts Liam had established for his other code listings. See the previous Blog Entry (getting ready for open source) for instructions.

We now have 2 copies of the code on our PC (one is in the git location and the other is in the RDi location) so we will need to copy the new member to the Git location for Git to pick it up. We did a similar process (reversed) when importing the code from Git to RDI.  

Note: – I am sure we could force the location to be the same (Git would need to be forced into the RDi location as we create the RDi workspace first) but as we have already gone this far down this route we will stick with it.

Copy RDi copy of source to Git location

Copy RDi copy of source to Git location


Once the object has been copied to the location we can refresh the Git perspective to see the new object has now been added to the QSOURCE directory. Lets add the new object to the staged changes.

Add new object to staged changes

Add new object to staged changes


At this stage we would simply push those changes to the master branch. Once this is done the source will now become part of the master branch, it will not form part of the release but the source will be available for all to see.

Unfortunately we are not allowed to update the master branch so the request was rejected. We need the Owner to allow us to commit (push) changes before we can carry out the final stage. Once we have permission and have decided on which branch (new?) we are to to commit the changes to we just need to add the commit message and press the commit and push button to get our source changes to the remote repository.

Enjoy…

Chris…