As you may have noticed, running
origen -h gives you a different set of commands
depending on where you run. When you
invoke Origen, one of the first things it will do is figure out what
invocation you’ve issued. The type of invocation isn’t something you need to control neccessarily,
but its important to understand why Origen’s behavior seems to arbitrarily change.
When you invoke Origen from within an application (or a plugin), you’re using Origen’s
This will most likely be the invocation used for any test or product engineer that is not creating a new application.
You’ll notice that when you first run
Origen from an application, you’ll see Bundler start to do some stuff… but what’s it doing? Bundler is building
up a custom
bin folder (
lbin, to be exact) which it will channel future invocation within the
application through. This ties this particular application to the gems specified in the
Gemfile and gives
So, what does that mean? Application invocations begin by booting up the application and all needed plugins. The
best way to see that will be to just run
origen -h from inside and outside an appication. When running
from within an application, you’ll get the
core application commands,
any Shared Commands from plugins, and any
Global Commands from plugins.
Global Invocations are the opposite of the aforermentioned
Application Invocations. These
invocations are obviously for when origen is run without any application.
The default core global commands are just
interactive. This makes sense, since its not
appropriate to create a new application if you’re already running from one, and when there is no application you’ll
most likely want to create a new one. You can see
here for creating a new application.
However, global invocations can also run other
global commands. This allows Origen to become a platform
for tool distribution, allowing for developers who use Origen to use all that Origen offers to build and distribute
other tools or scripts.
global commands may require a bit of additional setup. The commands that are available depend on
how exactly the
global invocation was induced. There are multiple ways to do this, as described in
the next section.
Note that this section only covers invocations. For a guide on how to actually create global commands, please see the section on global commands.
For new Origen users, this will be the most likely way of globally invoking Origen. This runs Origen straight from
the system installed gem (i.e., what was installed when you ran
gem install origen).
Origen invocations stemming from the this are known as
When these occur, Origen will search through all of the dependencies of each gem that is currently installed on the
system. If any of these gems have
origen as a dependency, then Origen will assume that it is a plugin and
boot that gem during Origen’s own booting process. Thus, it is possible to install plugins that have
global commands and also have them active by just running
Since these are available at the system level, if this is done on a shared system or on a server, all users will see those commands become available.
System invocations have the potential problem of requiring administrative access rights. When running on your own
system, this is not an issue, but when run on corporate accounts, most users won’t have these permissions.
User installations are more involved. These require using the
to indicate to Origen that you have a global
Gemfile setup somewhere. The full details are beyond a
startup guide, so this is marked as an
advanced topic and can be found here
Please don’t let that scare you away. However, a tool distribution platform is not Origen’s primary purpose, so unless you know you’ll need it, you can skip the advanced topic until you have more familiarity with Origen.
The basic procedure is:
- Create a custom site config in your Origen home directory.
- Enable users installs.
- Add dependencies to your user
Not that bad, right? If this seems like something you’d like to tackle now, go ahead and check out the topic here.
Once this is setup, invoking Origen through this
Gemfile is known as
Tool Repo invocations look very similar to user invocations. However, the usage for these is different.
These installations are built and maintained by an experience user and has the purpose of giving a set of users, or
users running from a particular directory, access to a pre-built dependency set.
At this point, you will most likely be a user of such an invocation. If so, you would have received some instructions from the installation manager on how to use it.
Setting these up is an involved process. An advanced topic on this is also
available in the advanced topics.
For now, that is all that will be said on
Tool Repo invocations.
application invocations, are handled independently. That is, installing a gem in the system ruby, or installing it in your
user installwill NOT enable that gem to be used in all your applications. Likewise, installing a gem in the system ruby will not make it attainable automatically in all tool repo installs or in your user install. This is so the
Gemfileremains the master dependency list, with the only exception being the system install which has no
Gemfile. So, if you want to use a specific gem for all your applications, tool repo installs, and your own user install, you will have to add it to the