Common classes with JSON library representation
I have attempted to use git submodules on our AngularJS/Node.js application
and gave up on it because of the potential for problems and how cumbersome
it was to use. The problems with submodules are well-documented all over
the Internet. One such example is here: < codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/>.
I would advise you to heed those who tell you to stay away from them and if
you must, look at one of the alternative approaches.
We used to have two separate repos for frontend and backend and
theoretically, they were independent of each other. There were two problems
with that approach. First, a coherent release consists of a particular
changeset of the frontend with a particular changeset of the backend.
Complete separation of frontend and backend is a myth even if the frontend
only interacts with the backend via a RESTful interface. When the model
changes in the backend and new API endpoints are exposed, an older version
of the frontend will not even know of the existence of those endpoints,
much less be able to do anything with them.
Second, there are very good reasons to share code between the frontend and
backend. We have data validation classes that both the frontend and backend
use, for example.
Our solution was to combine the frontend and backend repos into one repo.
That is probably not appropriate for you.
What you are pointing to is an architectural issue, that is, the lack of
any coherent module/packages system for Omnis. Node.js has npm modules < docs.npmjs.com/>. Python has modules which are packaged < packaging.python.org/>. Django created applications < docs.djangoproject.com/en/dev/intro/reusable-apps/>, which enable
one to “plug in” code written by others with minimal fuss into your Django
projects. The solution to this issue is not to come up with better revision
control tools to work around the lack of any well-defined method of
interfacing “foreign” code into your Omnis libraries. It’s to create a
well-documented and well-defined interface mechanism for Omnis. That
well-defined and well-documented interface very well might be a library.
However, if I had a bunch of Omnis libraries, mine and others, how would I
know which changesets/versions constitute a coherent release?
In Python, we can capture which modules at what versions are being used in
a particular environment into a text file, requirements.txt, which is only
called that by convention, not by any hard rule. Here is an excerpt from
one of my projects.
In that particular project, there are 38 lines in requirements.txt. That
file is kept under revision control. Implicit in that statement is the
requirements.txt can change over time. I can re-create that project exactly
as it was at a particular changeset by using the Python package installer,
pip, by doing: “pip install -r requirements.txt”.
Node.js has a similar mechanism, package.json, which I think is even more
sophisticated. We can specify production or development only dependencies,
and various scripts to test, deploy, and run the application in this file.
Again, that is kept under revision control.
Omnis doesn’t have anything like this so if you really want to deal with
this issue, that is the place to start. Agree on a mechanism, ideally
something that can be automated with a script (use OmnisCLI – hint, hint),
that would enable someone to take your package.json, execute “om install
package.json” and assuming that all the requirements within package.json
are somewhere on the network, whether local or on the Internet, you can
reconstitute that Omnis application. A specification, implementation, and
documentation of Omnis library packaging is a necessary but insufficient
condition for making all this work. You’ll still need a package directory
that can be explored. You can’t just say, “look for the Omnis tag on
+ 1 647-778-8696
On Mon, Oct 23, 2017 at 11:55 AM, Alex Clay <email@example.com> 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 library.
> 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
> > On Oct 23, 2017, at 11:41, Graham Stevens <firstname.lastname@example.org>
> > Hi $all,
> > I realize this question is probably a bit early as most of us aren’t yet
> using the new JSON library export but I’ll ask it anyway. I probably
> should have brought it up at EurOmnis but it has only just occurred to me
> now I am back in the office.
> > Has anybody put thought into a satisfactory way to handle classes which
> are common to more than one library/application? We have multiple
> applications and an infrastructure library of common code in our Omnis
> VCS. This library’s classes are linked to most of our applications and
> this works very well in the context of building our libraries from the
> VCS. But I don’t immediately see an obvious way to handle this in a
> multiple repository setup like Git. It may just be that I don’t yet have a
> full understanding of Git but I would appreciate any thoughts you may have
> on the topic.
> > Thanks and best regards,
> > Graham
> > PS. It was great to see and catch up with everyone at the conference.
> > _____________________________________________________________
> > Manage your list subscriptions at lists.omnis-dev.com
> Manage your list subscriptions at lists.omnis-dev.com
Manage your list subscriptions at lists.omnis-dev.com