Deploying updated libraries (was Replacing Omnis VCS with SVN/Git type repository)

[Alex Clay]

Hi Graham.

This is excellent to hear! We have a similar transition planned to break our associated classes out to separate libraries so we can build our Studio projects out of Git. It's good to know we won't be the first down that path. :)

We built an app_loader.lbs which accomplishes a similar task as your launcher.lbs, but with a slightly different approach. Extra libraries are always located in a lib/ directory in the same location as startup/. We load these libraries first with the !!! prefix to avoid and startup tasks, then load the final library from startup/.

The other difference is that we track an application build number. We use this to compare the libraries inside the application's firstruninstall/ with the user's %LOCALAPPDATA% or ~/Library/Application Support folder and, if different, update the user-writable libraries with the "official" copies from the application.

How are you handling updating the application libraries and the user-writeable ones? I'd love to converge our solutions and provide something for the community. I feel managing these two copies of libraries is something that Omnis itself doesn't solve well but requires a bullet-proof solution.

Alex


> On Jan 2, 2018, at 08:23, Graham Stevens <graham.stevens at gmail.com> wrote:
> 
> 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
> 
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com