Android Emulator
Los ficheros system.img que utiliza el emulador de Android para arquitecturas ARM están en formato YAFFS2. Si queremos modificar dichas imágenes para incluir, por ejemplo, las Google Apps, podemos seguir los siguientes pasos para desempaquetar/modificar/reempaquetar dicha imagen.

Preparación

Antes de nada, necesitamos tener en nuestro sistema un par de herramientas:

Extracción de system.img

~/work/redo_system$ cp $ANDROID_HOME/add-ons/addon-google_apis-google_inc_-14/images/armeabi-v7a/* .
~/work/redo_system$ mkdir unpacked
~/work/redo_system$ cd unpacked/
~/work/redo_system/unpacked$ unyaffs ../system.img

Modificación/Inclusión de aplicaciones

~/work/redo_system/unpacked$ cd app
~/work/redo_system/unpacked/app$ cp ~/work/gapps-jb-20121011-signed/system/app/Phonesky.apk .
~/work/redo_system/unpacked/app$ cp ~/work/gapps-jb-20121011-signed/system/app/GoogleServicesFramework.apk .
~/work/redo_system/unpacked/app$ cp ~/work/gapps-jb-20121011-signed/system/app/GoogleLoginService.apk .

Reconstrucción de system.img

~/work/redo_system/unpacked/app$ cd ../..
~/work/redo_system$ rm system.img
~/work/redo_system$ mkyaffs2image unpacked system.img

Apuntar nuestro AVD a nuestra nueva imágen


~/work/redo_system$ nano ~/.android/avd/jb.avd/config.ini
image.sysdir.1=/home/rubensa/work/redo_system/

NOTA: Al usar esta nueva versión de system.img en el emulador es conveniente eliminar los archivos cache.img, userdata.img y userdata-qemu.img del AVD ya que estos podrían no ser ya compatibles con la nueva imagen del sistema.

vía

Get Adobe Reader
Instalación

  • sudo dpkg –add-architecture i386
  • sudo apt-get update
  • sudo apt-get install wget curl nspluginwrapper cups-pdf libgtk2.0-0 libxml2
  • sudo apt-get install libxml2:i386 libgtk2.0-0:i386 gtk2-engines-murrine:i386 gtk2-engines-pixbuf:i386
  • wget -c ftp://ftp.adobe.com/pub/adobe/reader/unix/9.x/9.5.5/enu/AdbeRdr9.5.5-1_i386linux_enu.deb
  • sudo dpkg -i AdbeRdr9.5.5-1_i386linux_enu.deb

Arranque

  • acroread

Desinstalación

  • sudo apt-get remove adobereader-enu

Subversion Logo
Tipos de merge:

  • sync o catch-up: un merge que introduce en la rama destino todos los cambios de la rama fuente que “todavía no tenemos” en la rama destino.
  • cherry-pick: un merge que introduce un o más cambios específicos de la rama fuente en la rama destino.
  • reintegrate: similar a un sync merge, pero pensada para ser utilizada en la otra dirección.

Asumamos un orden parcial entre branches, de tal modo que cada branch tiene (0 o más) Feature Banches que son menos estables que ella, y Release Branches que son más estables que ella, y ella se considera el padre de cada una de estas. Un merge se puede realizar entre una branch padre y uno de sus Feature o Release branches inmediatas, y en ninguna otra parte.

  • Un merge a una Feature Branch desde su padre normalmente es un catch-up.
  • Un merge desde una Feature Branch a su padre normalmente es un reintegrate.
  • Un merge a una Release Branch desde su padre normalmente es un cherry-pick.
  • Un merge desde una Release Branch a su padre podría ser un catch-up o un cherry-pick. (¿Funciona un catch-up correctamente y has hecho cherry-picks en la otra dirección? Puede que no.)

Tomcat
Para habilitar las trazas de logging tal y como se utilizan en la instalación por defecto de Tomcat 7, pero dentro del Eclipse usando WTP, debemos seguir los siguientes pasos:

  1. En la vista Project Explorer (o Navigator o Package Explorer) vamos a Servers –> Tomcat v7.0 Server at localhost-config –> Botón derecho –> Import –> General –> File System –> Next –> Navegamos a la carpeta $CATALINA_BASE/conf/ (donde $CATALINA_BASE es la carpeta de instalación del Tomcat 7) –> Seleccionamos el fichero logging.properties –> Finish
  2. Vamos a Run –> Run Configurations… –> Apache Tomcat –> Tomcat v7.0 Server at localhost –> Arguments –> Y en “VM arguments” añadimos:

    -Djava.util.logging.config.file="${workspace_loc}/Servers/Tomcat v7.0 Server at localhost-config/logging.properties" -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

    –> Apply

NOTA: Es posible que el nombre de la carpeta de configuración del servidor (Tomcat v7.0 Server at localhost-config) sea diferente o que el nombre de la configuración del lanzador (Tomcat v7.0 Server at localhost) sea distinta. Será necesario ajustarla acorde a tu configuración particular.

Tomcat
Por defecto el nivel de logging definido en Tomcat 7 es INFO.

Con este nivel de logging, no se detalla ningún tipo de información acerca de la configuración del contexto JNDI que se define para cada módulo desplegado.

Si necesitamos “trazar” la definición de dichos contextos JNDI tenemos que activar el nivel DEBUG en la clase org.apache.catalina.core.NamingContextListener que, según el JavaDoc es una:

Helper class used to initialize and populate the JNDI context associated with each context and server

Para hacer esto, editamos el fichero $CATALINA_BASE/conf/logging.properties y añadimos al final algo así:


# To see debug messages in NamingContextListener
org.apache.catalina.core.NamingContextListener.level = FINE

Si además de trazar la definición de los contextos JNDI queremos trazar las consultas (lookups) que se realizan a dichos contextos, podemos activar la traza a nivel del paquete org.apache.naming añadiendo algo así:


# To see debug messages in org.apache.naming package
org.apache.naming.level = FINE

tattletale_logo_600px
¿Alguna vez te has encontrado un problema al ejecutar tu aplicación web porque varios de los ficheros jar incluidos tienen las mismas clases en diferentes versiones y la que coge el servidor de aplicaciones es la incorrecta?

Utilizando la herramienta Tattletale de JBoss y su plugin Maven, puedes encontrar fácilmente si tienes clases duplicadas en la carpeta WEB-INF/lib de tu WAR y más importante, hacer que falle la construcción automáticamente si eso ocurre, de modo que no sea demasiado tarde y te ocurra en producción.

Simplemente añade la siguiente configuración del plugin en el pom de tu WAR, en la sección build/plugins. También se puede utilizar en EAR, assemblies y otros tipos de proyectos.

	
<plugin>
  <groupId>org.jboss.tattletale</groupId>
  <artifactId>tattletale-maven</artifactId>
  <version>1.1.2.Final</version>
  <executions>
    <execution>
      <phase>verify</phase> <!-- needs to run after WAR package has been built -->
      <goals>
        <goal>report</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <source>${project.build.directory}/${project.build.finalName}/WEB-INF/lib</source>
    <destination>${project.reporting.outputDirectory}/tattletale</destination>
    <reports>
      <report>jar</report>
      <report>multiplejars</report>
    </reports>
    <profiles>
      <profile>java6</profile>
    </profiles>
    <failOnWarn>true</failOnWarn>
    <!-- excluding some jars, if jar name contains any of these strings it won't be analyzed -->
    <excludes>
      <exclude>persistence-api-</exclude>
      <exclude>xmldsig-</exclude>
    </excludes>
  </configuration>
</plugin>

Tendrás que añadir el repositorio Maven de JBoss a la sección repositories de tu POM, o a tu gestor de repositorios. Asegúrate de utilizar el repositorio que solamente contiene artefactos JBoss o podrías experimentar conflictos entre artefactos en ese repositorio y el repositorio Central de Maven.

<repository>
  <id>jboss</id>
  <url>https://repository.jboss.org/nexus/content/repositories/releases</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</repository>

Nota: Añadir repositorios extra es una fuente común de problemas que provoca construcciones más lentas (se consulta todos los repositorios en busca de artefactos).

vía

Maven
HAZ LA CONSTRUCCIÓN REPRODUCIBLE

* Especifica siempre una versión de los plugins Maven2
Modo incorrecto

<plugin>
 <groupid>org.apache.maven.plugins</groupid>
 <artifactid>maven-surefire-plugin</artifactid>
</plugin>

Modo correcto

<plugin>
 <groupid>org.apache.maven.plugins</groupid>
 <artifactid>maven-surefire-plugin</artifactid>
 <version>2.3</version>
 </plugin>

Esto importa porque si no pones la versión, maven2 utiliza por defecto la ULTIMA disponible.

Esto quiere decir que

  • el resultado del plugin puede ser impredecible si la implementación ha cambiado (características nuevas/eliminadas, …)
  • tu proyecto, sin saberlo, se convierte automáticamente en un beta-tester para plugins de terceros si la última versión es una SNAPSHOT

Las nuevas versiones de m2eclipse mostrarán una advertencia en la consola. Puede revisar también el plugin enforcer de maven.

Leer el resto de esta entrada »

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

A %d blogueros les gusta esto: