Replacing Omnis VCS with SVN/Git type repository

[Graham Stevens]

Hi All,

Here at Platform Independent Systems, we have a number of Omnis 
applications, covering desktop, JS client and thin client.  Until now, 
these libraries have been versioned using the Omnis VCS.  But with the 
advent of the new JSON representation of libraries and the desire within 
the community to open source more Omnis projects, I have been working on 
converting all our libraries.  We have now completed the work so we 
wanted to share our experiences with the Omnis community in the hope 
that it may encourage others to make the change.

The primary issue we had with the change was the existence of over 200 
classes which were shared by all our libraries.  The VCS had an 
"infrastructure" project that was used purely as a repository for the 
common classes and never built as an application - as all its classes 
were shared with all other projects and consequently included in the 
build of the other libraries.  We like this feature of the VCS and used 
it extensively although the VCS interface is a bit buggy and we had to 
manually adjust internal VCS records to keep things in pristine condition.

After posing the question on this list as to how to handle this 
situation with a Git type repository, and considering everyone’s input 
on the topic, we made the decision to keep these common classes in a 
library which would be a required constituent of any application.  On 
top of this we have a couple of applications that consist of a 
desktop/JS client that communicates with a RESTful server and these also 
had common classes particular to the application in question.  So there 
are three "common" libraries, one of which is common to all of the 
applications.  These "common" libraries exist as an integral part of an 
application but do not have startup tasks, they are purely class 
repositories.

Deciding on this structure was the easy bit, the time consuming part was 
the updating of the code in each application library to prefix each 
reference to a class with the "infra." or "appcommon." library in which 
it now resides.

Having made all these changes, we then had to export all the libraries 
to their JSON representation.  This presented us with another few issues 
peculiar to the JSON exports.  To name a couple that came up:

-  Failing to have one or other of the required libraries open before export
-  References in legacy code to non-existent variables, ie. #???
-  Duplicate names for objects on window and remote form classes

Once we had fixed all the issues and successfully placed all our 
libraries in our SVN repository (we already had a SubVersion server for 
another project we had worked on), we had to come up with a replacement 
for the VCS "Build Project" command to deploy our apps. This is the 
point where Alex Clay's presentations at EurOmnis and his libraries 
became invaluable and we have to offer him a huge thank you for open 
sourcing them: omniscli.lbs (https://github.com/suransys/omniscli) and 
ci.lbs (https://github.com/omnis-ci/ci.lbs).  These two libraries now 
enable us to script the building of our applications ready for 
deployment.  The omniscli library accepts command line inputs to control 
the ci library which builds the libraries from the JSON source code.  I 
submitted a small enhancement to the ci.lbs repository to extend the 
functionality to accept an optional list of the dependant libraries' 
paths (infra and appcommon) to be opened before building the application 
library.

Not being particularly adept at shell scripting, I have created a small 
Python script which accepts the name of the library to be built.  It 
then calls "svn export" to copy the source code from our SVN server to a 
local directory and then passes the path via omniscli to ci.lbs to build 
the library. And this all takes no more time than opening the old VCS 
and building a library.

The final piece of the puzzle is the opening of our application 
library.  We used to place our library in the Omnis startup folder but 
now that we have one (or two) required libs to open before the main 
library this isn't always going to work.  Libraries in the startup 
folder seem to be opened in alphabetical order which isn't always 
ideal.  So to circumvent this, I created a launcher.lbs that is placed 
in the startup folder. This library's sole purpose is to read an 
initialisation file containing the paths to the other libraries, open 
them in the order they appear in the file and then close itself.  The 
added advantage is that the libraries can reside anywhere you like.  If 
anyone thinks it might be useful, we have put it on Github here: 
https://github.com/PISL/omnis-launcher

Now that I have successfully converted our libraries to JSON, we will be 
releasing some of our code to the community on Git. (Doug, this will 
include the MailChimp stuff!)

Apologies for the length of this post but I hope it may be of interest 
to some of you.

And I wish everyone all the best for 2018.

Regards,
Graham