Common classes with JSON library representation
Thanks for your thoughts.
Option 1 is what I was considering and it fits for us because we already
have the common code in a separate library. This library doesn’t
normally get built and distributed but it shouldn’t be too difficult to
include it in our build process. Of course, we still have the task of
identifying all the instances of the common classes in our other
libraries and pointing them to the core library.
On 24/10/2017 09:27, Alex Clay wrote:
> Hi Graham,
> Associated classes are our biggest sticking point for moving to git.
> There are a couple solutions I’ve come up with so far:
> 1) Move this code to a separate Omnis library
> 2) Use a git submodule, which lets you merge multiple repositories
> together into a single working copy
> We’re proceeding with option 1, mostly by moving the project-specific
> classes to separate libraries and leaving the rest in a single core
> Using submodules would work in theory, but it’s more complicated. The
> workflow would be:
> 1) Create a repository for your common code
> 2) Include this repository in your project as a submodule
> 3) Export your lib to JSON
> 4) Copy the common classes into the directory for the common submodule
> 5) Commit and push your changes
> When building out, you would pull remote updates, then copy the common
> code back into the JSON source for your library. Rebuilt the lbs from
> the repository and you should be good to go.
> The trick is identifying which classes are common and which aren’t.
> This is one reason we’re just going to split up the project—this
> identification is easy to express by dividing classes into libraries.
> I’ll make a caveat that this is all theoretical—I haven’t tried using
> the submodules to see if there is a better solution. If someone does
> find a good way to express the Omnis VCS’ concept of associations in
> git, please share!
Manage your list subscriptions at lists.omnis-dev.com