Difference between pages "Translations:Doc: Using local manifests/8/es" and "Doc: Using manifests/es"

From CyanogenMod
(Difference between pages)
Jump to: navigation, search
(Created page with "Hay una manera mejor de hacerlo. Utilizar un manifiesto local.")
 
(Created page with "Hay una manera mejor de hacerlo. Utilizar un manifiesto local.")
 
Line 1: Line 1:
 +
<languages />
 +
== Introducción ==
 +
 +
Normalmente, cuando usted
 +
 +
Normalmente, cuando usted ejecuta el comando <code>repo sync</code>, docenas de repositorios [[git]] son actualizados desde el [www.github.com/cyanogenmod cuanta de CyanogenMod en GitHub] a su computadora.
 +
 +
=== El manifiesto general: <code>manifest.xml</code> ===
 +
 +
Existe un listado maestro de repositorios que conjuntamente componen el código fuente de CyanogenMod. El listado maestro, o "'''[[Doc:_manifests|manifiesto]]'''", se encuentra localizado en el código fuente en el directorio oculto <code>.repo</code> (relativo al directorio raíz del código fuente). El directorio <code>.repo</code> fue creado la primera vez que ejecuto el comando <code>repo init</code> antes de la primera descarga del código.
 +
 +
The file is called, appropriately enough, <code>manifest.xml</code>, and is formatted in [[wikipedia:xml|XML]] markup and contains information regarding which git repositories to use, where they are located on the internet, where to put them in the source code directory, and what branch of the git repository is used.
 +
 +
{{note|note=El fichero de manifiesto es actualizado automáticamente cada vez que usted ejecuta el comando <code>repo sync</code>. De esta manera, el listado de todos los repositorios que componente CyanogenMod son mantenidos actualizados junto con el código.}}
 +
 +
Si desea cambiar dicho listado, puede editar el fichero <code>manifest.xml</code> directamente. De cualquier manera, esto hará que su copia local del fichero manifiesto entre en conflicto con la versión oficial. Esto podría crearle problemas cuando la versión oficial del mismo sea actualizada, ya que estaría en conflicto con sus cambios.
 +
 
Hay una manera mejor de hacerlo. Utilizar un manifiesto local.
 
Hay una manera mejor de hacerlo. Utilizar un manifiesto local.
 +
 +
== The local manifest ==
 +
 +
Creating a '''local manifest''' allows you to customize the list of repositories on your copy of the source code by overriding the official manifest.  In this way you can add, remove, or replace source code in the official manifest with your own.  By pointing to new git repositories, (which need not even reside on the github site,) you can continue to synchronize with the <code>repo sync</code> command just as you would before.  Only now, not only are official updates pulled from the regular manifest, but the remote git repositories specified in ''your'' manifest will also be checked, and new updates pulled to your source code.
 +
 +
=== Overriding the manifest ===
 +
 +
To override the contents of <code>manifest.xml</code>, you will need to write (or borrow) a plaintext XML file that defines the repos you want to pull from. There are two ways you can do this. The old deprecated way is to create a <code>local_manifest.xml</code> in the <code>.repo</code> directory. The new way (available in repo versions >= 1.19) is to create a folder called <code>local_manifests</code> and put that inside the <code>.repo</code> directory, then put your XML inside that directory. You can place as many override files in <code>.repo/local_manifests</code> as you like and <code>repo</code> will pick them up during the next sync. You can call the files anything you like as long as they end in <code>.xml</code>.
 +
 +
=== An example ===
 +
 +
Take a look at the following <code>local_manifest.xml</code> file.  Then we'll discuss how it works.
 +
<code><?xml version="1.0" encoding="UTF-8"?>
 +
    <manifest>
 +
 +
      <remote name="omap" fetch="git://git.omapzoom.org/" />
 +
 +
      <remove-project name="CyanogenMod/android_hardware_ti_omap3" />
 +
 +
      <project path="hardware/ti/omap3" name="repo/android/hardware/ti/omap3" remote="omap" revision="jellybean"/>
 +
 +
    </manifest></code>
 +
The first two lines containing <code><?xml  version="1.0" encoding="UTF-8"?></code> and <code><manifest></code> are standard, as is the last line, which contains <code></manifest></code>.
 +
 +
Next, a '''remote''' for [[git]] is declared and given the name "omap".  (If you're not familiar with the concept of a remote in git, it essentially refers to a place (and method) for accessing a git repository.  See [http://git-scm.com/book/en/Git-Basics-Working-with-Remotes here] for more info.)  In this case, omapzoom.org is a site that contains special up-to-date repositories for Texas Instrument's OMAP platform.
 +
 +
The next line removes a project (the one at [http://www.github.com/cyanogenmod/android_hardware_ti_omap3 http://www.github.com/cyanogenmod/android_hardware_ti_omap3]) declared in the original <code>manifest.xml</code>.  It will now no longer be synced with <code>repo sync</code>.
 +
 +
The next line defines a ''new'' project.  It replaces the one that was removed (from '''github.com/cyanogenmod''') with one from Texas Instruments, using the "omap" remote that was defined above.
 +
 +
When adding a new project that ''replaces'' an existing project, you should always remove that project before defining the replacement.  However, not every new project need replace an existing cyanogenmod project.  You can also simply add a brand-new project to the source code, such as when you want to [[Doc:_adding_your_own_app|add your own app]] to the build.
 +
 +
Note that when adding new projects, there are at least three parts defined:
 +
 +
* <code>remote</code> -- the name of the remote.  this can be one that was defined in either the regular <code>manifest</code> or <code>local_manifest.xml</code>.
 +
 +
* <code>name</code> -- the name of the git project-- for github it has the format ''account_name/project_name''.
 +
 +
* <code>path</code> -- where the git repository should go in your local copy of the source code.
 +
 +
* <code>revision</code> -- (OPTIONAL) which branch or tag to use in the repository.
 +
 +
After adding <code>.repo/local_manifest.xml</code>, you should be able to <code>repo sync</code> and the source code should be updated accordingly.
 +
 +
=== Errors ===
 +
 +
If you receive any errors, double-check to make sure that the XML is "valid"-- that is, ensure that the file contains proper XML by verifying all < and > brackets match, and that all open quotations are closed properly, etc.  Other problems may include missing values, such as not defining a remote and then using it.
 +
 +
=== See also ===
 +
 +
* [http://stackoverflow.com/questions/5672394/using-a-local-manifest-xml-with-repo Stack Overflow]

Revision as of 13:54, 8 May 2013

Other languages:English 100% • ‎Spanish 0% • ‎French 0% • ‎Japanese 0% • ‎Chinese (China) 0%

Introducción

Normalmente, cuando usted

Normalmente, cuando usted ejecuta el comando repo sync, docenas de repositorios git son actualizados desde el [www.github.com/cyanogenmod cuanta de CyanogenMod en GitHub] a su computadora.

El manifiesto general: manifest.xml

Existe un listado maestro de repositorios que conjuntamente componen el código fuente de CyanogenMod. El listado maestro, o "manifiesto", se encuentra localizado en el código fuente en el directorio oculto .repo (relativo al directorio raíz del código fuente). El directorio .repo fue creado la primera vez que ejecuto el comando repo init antes de la primera descarga del código.

The file is called, appropriately enough, manifest.xml, and is formatted in XML markup and contains information regarding which git repositories to use, where they are located on the internet, where to put them in the source code directory, and what branch of the git repository is used.

Note:

El fichero de manifiesto es actualizado automáticamente cada vez que usted ejecuta el comando repo sync. De esta manera, el listado de todos los repositorios que componente CyanogenMod son mantenidos actualizados junto con el código.

Si desea cambiar dicho listado, puede editar el fichero manifest.xml directamente. De cualquier manera, esto hará que su copia local del fichero manifiesto entre en conflicto con la versión oficial. Esto podría crearle problemas cuando la versión oficial del mismo sea actualizada, ya que estaría en conflicto con sus cambios.

Hay una manera mejor de hacerlo. Utilizar un manifiesto local.

The local manifest

Creating a local manifest allows you to customize the list of repositories on your copy of the source code by overriding the official manifest. In this way you can add, remove, or replace source code in the official manifest with your own. By pointing to new git repositories, (which need not even reside on the github site,) you can continue to synchronize with the repo sync command just as you would before. Only now, not only are official updates pulled from the regular manifest, but the remote git repositories specified in your manifest will also be checked, and new updates pulled to your source code.

Overriding the manifest

To override the contents of manifest.xml, you will need to write (or borrow) a plaintext XML file that defines the repos you want to pull from. There are two ways you can do this. The old deprecated way is to create a local_manifest.xml in the .repo directory. The new way (available in repo versions >= 1.19) is to create a folder called local_manifests and put that inside the .repo directory, then put your XML inside that directory. You can place as many override files in .repo/local_manifests as you like and repo will pick them up during the next sync. You can call the files anything you like as long as they end in .xml.

An example

Take a look at the following local_manifest.xml file. Then we'll discuss how it works.

<?xml version="1.0" encoding="UTF-8"?>
   <manifest>

     <remote name="omap" fetch="git://git.omapzoom.org/" />

     <remove-project name="CyanogenMod/android_hardware_ti_omap3" />

     <project path="hardware/ti/omap3" name="repo/android/hardware/ti/omap3" remote="omap" revision="jellybean"/>

   </manifest>

The first two lines containing <?xml version="1.0" encoding="UTF-8"?> and <manifest> are standard, as is the last line, which contains </manifest>.

Next, a remote for git is declared and given the name "omap". (If you're not familiar with the concept of a remote in git, it essentially refers to a place (and method) for accessing a git repository. See here for more info.) In this case, omapzoom.org is a site that contains special up-to-date repositories for Texas Instrument's OMAP platform.

The next line removes a project (the one at http://www.github.com/cyanogenmod/android_hardware_ti_omap3) declared in the original manifest.xml. It will now no longer be synced with repo sync.

The next line defines a new project. It replaces the one that was removed (from github.com/cyanogenmod) with one from Texas Instruments, using the "omap" remote that was defined above.

When adding a new project that replaces an existing project, you should always remove that project before defining the replacement. However, not every new project need replace an existing cyanogenmod project. You can also simply add a brand-new project to the source code, such as when you want to add your own app to the build.

Note that when adding new projects, there are at least three parts defined:

  • remote -- the name of the remote. this can be one that was defined in either the regular manifest or local_manifest.xml.
  • name -- the name of the git project-- for github it has the format account_name/project_name.
  • path -- where the git repository should go in your local copy of the source code.
  • revision -- (OPTIONAL) which branch or tag to use in the repository.

After adding .repo/local_manifest.xml, you should be able to repo sync and the source code should be updated accordingly.

Errors

If you receive any errors, double-check to make sure that the XML is "valid"-- that is, ensure that the file contains proper XML by verifying all < and > brackets match, and that all open quotations are closed properly, etc. Other problems may include missing values, such as not defining a remote and then using it.

See also