2012's
&TCAR; development was eventually stopped at November 2011
until July 2012 when it was decided to make the
centos-art.sh script a bit more
customizable than it presently was. For example, it was
considered as a need that functionalities inside the
centos-art.sh script must be not just
conceived independent one another but reusable in different
contexts.
As consequence of this autonomy we want to have among
functionalities, the procedure used to locale messages inside
the centos-art.sh script had to be
modified in order to accept such pluggable behavior into the
script. We cannot have a single
centos-art.sh.po file for all the
functionalities because all functionalities are not used in
the same context. Instead, it is required that each
functionality has its own messages.po file in order to
treat them individually. Otherwise, we would end up having
translations for functionalities that we don't need or use in
our current context.
As an example, consider a situation where you are working on
the corporate identity of &TCP; and you need to start a new
corporate identity project for another organization. You want
to keep the directory structure of &TCAR; and its automation
tool, the centos-art.sh script. Your new
project requires you to introduce new functionalities to
centos-art.sh that don't fit the needs of
&TCP; (e.g., you want to introduce a
report functionality to mesure how much
connect time do you consume through your PPP internface.).
To solve this issue, you need to mix specific parts of
different central repositories into one single working copy.
This is the working copy you'll use to manage your new
project. The ,
illustrates how the render functionality
living in &TCAR; has been integrated into the working copy of
your new project.
Mixing automation functionalities.
Mixing automation functionalities.
/home/al/Projects/Myapp/
`-- trunk/
|-- Locales/
| `-- Bash/
| |-- Functions/
| | |-- Render/ <--| from https://projects.centos.org/svn/artwork/
| | | `-- es_ES/
| | | |-- messages.po
| | | `-- messages.pot
| | `-- Report/
| | `-- es_ES/
| | |-- messages.po
| | `-- messages.pot
| `-- es_ES/
| |-- LC_MESSAGES/
| | `-- centos-art.sh.mo
| |-- centos-art.sh.po
| `-- centos-art.sh.pot
`-- Scripts/
`-- Bash/
|-- Functions/
| |-- Render/ <--| from https://projects.centos.org/svn/artwork/
| `-- Report/
`-- myapp.sh
At this point you find yourself working with a mix of two
different central repositories in the same working copy. One
repository provides your organization files. The other
repository provides the files of render
functionality at &TCAR;. In this environment, all updates
commited to the render functionality at
&TCAR; will be available to you too, the next time you update
your working copy.
Understanding the need of mixing different repositories into a
single working copy is an important setp for reusing the
functionalities that come with centos-art.sh script, but it is
not enough if you want to customize the information produced
by it. By default, the centos-art.sh script uses information
related to &TCP;. You probably need to change this if you are
producing images to a different organization than &TCP;. For
example, some of the information you might need to change
would be the copyright holder, brands, domain names, mailing
lists, and so forth. To change this information you need to
duplicate the file centos-art.sh and
rename it to something else. Later, you need to edit the
renamed version and change variables inside according your
needs. In , we
used the name ispadm.sh instead of
centos-art.sh so the information we set
inside it could reflect the specific needs that motiveted the
creation of a new project without affecting those from &TCP;.
Most of the information you need to change in your duplicated
version of centos-art.sh file is
controled by a set of read-only variables. You modify these
variables here and they will be available all along the script
execution time. For example, you can change the value of
CLI_WRKCOPY variable inside your duplicated
version of centos-art.sh to change the
absolute path of your working copy.
Setting the absolute path of your working copy to
something different than
/home/centos/Projects/artwork will
provoke that some components inside &TCAR; be processed
correctly while others don't.
For example, SVG design models will be processed correctly
but CSS files won't. This is because before processing
SVG files we expand translation markers inside them create
a temporal file and then process the temporal file instead
of the original SVG file. In the case of CSS files doing
the same isn't appropriate.