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