Posts filed under ‘Entorno Desarrollo’

Eliminar caché de acceso a unidades de red en Windows XP

Cuando accedemos a un recurso compartido o unidad de red en Windows XP (por ejemplo desde ejecutar en el menú de inicio o desde la barra de direcciones del explorador de Windows), nos pregunta el usuario y la contraseña. El usuario que introducimos se queda cacheado de forma que las siguientes veces que accedemos ya no nos lo vuelve a preguntar.

Esto que es cómodo en principio, hay algunas ocasiones en que no es lo deseable. Por ejemplo si queremos ver si otro usuario tiene acceso.

Yo al final la manera más cómoda que he encontrado para eliminar esa caché es a través de la línea de comandos.

Para mostrar las unidades a las que estamos conectados:

net use

net use

Para eliminar la caché de una de las entradas:

net use \\unidad /delete
net use \\ip /delete

net use delete

También podemos eliminar todas las entradas:

net use * /delete

Podemos comprobar que las entradas se han eliminado.

net use

Ahora si volvemos a intentar entrar en el recurso compartido nos volverá a solicitar el usuario y la contraseña.

Pongo el enlace a la ayuda completa del comando net use (en inglés Inglés).

Anuncios

26 abril 2013 at 7:38 pm 1 comentario

Análisis estático de código en Hudson para proyectos Ant

En esta entrada vamos a explicar cómo configurar algunas herramientas de análisis estático de código en Hudson para proyectos que utilicen Ant.

Partimos de un servidor Hudson instalado (y con una JDK y Ant configurados) y un proyecto que utilice Ant para su construcción (tendremos su build.xml que compila las fuentes y crea un jar por ejemplo).

Por ahora vamos a integrar tres herramientas de análisis estático de código: PMD, CPD (integrado en PMD) y FindBugs. Necesitaremos descargar y extraer en un directorio ambas herramientas.

Partimos de un script de Ant como el que sigue:

<?xml version="1.0"?>

<project name="TCYMU" default="compile" basedir=".">

	<property name="src.dir" value="${basedir}/src"/>
	<property name="lib"	value="${basedir}/lib"/>
	<property name="classes"	value="${basedir}/classes"/>

	<target name="clean" description="Limpia el proyecto">
		<delete dir="${classes}"/>
		<delete dir="${dist}"/>
	</target>	

	<target name="init" description="Crea el directorio de compilacion y destino" depends="clean">
		<mkdir dir="${classes}"/>
		<mkdir dir="${dist}"/>
		<path id="compile.class.path">
			<pathelement path="${lib}/*.jar"/>
		</path>
	</target>	

	<target name="compile" description="Compilacion" depends="init">
		<javac debug="on" srcdir="${src.dir}" destdir="${classes}" classpathref="compile.class.path"/>
	</target>

</project>

Crearemos una nueva tarea en Hudson, introduciremos un nombre y seleccionaremos la opción de “Crear un proyecto de estilo libre”.

Después seleccionaremos una JDK, configuraremos el control de versiones (en mi caso Subversion) y en la sección de “Ejecutar” seleccionaremos “Ejecutar Ant” e introducimos el nombre de nuestra tarea de Ant para compilar. Con esto ya podríamos lanzar la primera ejecución en Hudson para comprobar que funciona.

Para integrar los tres análisis voy a utilizar una misma estrategia basada en variables de entorno que nos permitirá que nuestra configuración Ant sea válida tanto en local como en el servidor Hudson. Para ello en la configuración de Hudson definiremos dos variables de entorno que apunten a los directorios de PMD y FindBugs.

Hecho esto modificamos el build.xml para incluir las nuevas tareas:

<?xml version="1.0"?>

<project name="TCYMU" default="compile" basedir=".">

	<property environment="env"/>
	<property name="src.dir" value="${basedir}/src"/>
	<property name="lib"	value="${basedir}/lib"/>
	<property name="classes"	value="${basedir}/classes"/>
	<property name="reports" value="${basedir}/reports"/>

	<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask">
		<classpath>
			<pathelement location="${env.PMD_HOME}/lib/pmd-4.2.5.jar"/>
		</classpath>
	</taskdef>

	<taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask">
		<classpath>
			<pathelement location="${env.PMD_HOME}/lib/pmd-4.2.5.jar"/>
		</classpath>
	</taskdef>

	<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask">
		<classpath>
			<pathelement location="${env.FINDBUGS_HOME}/lib/findbugs-ant.jar"/>
		</classpath>
	</taskdef>

	<target name="clean" description="Limpia el proyecto">
		<delete dir="${classes}"/>
		<delete dir="${dist}"/>
	</target>

	<target name="cleanReports" description="Elimina el directorio de compilacion y destino">
		<delete dir="${reports}"/>
	</target>

	<target name="init" description="Crea el directorio de compilacion y destino" depends="clean">
		<mkdir dir="${classes}"/>
		<mkdir dir="${dist}"/>
		<path id="compile.class.path">
			<pathelement path="${lib}/*.jar"/>
		</path>
	</target>	

	<target name="compile" description="Compilacion" depends="init">
		<javac debug="on" srcdir="${src.dir}" destdir="${classes}" classpathref="compile.class.path"/>
	</target>

	<target name="pmd">
		<mkdir dir="${reports}"/>
		<pmd rulesetfiles="ruleset.xml">
			<formatter type="xml" toFile="${reports}/pmd.xml"/>
			<fileset dir="${src.dir}">
				<include name="**/*.java"/>
			</fileset>
		</pmd>
	</target>

	<target name="cpd">
		<mkdir dir="${reports}"/>
		<cpd minimumTokenCount="50" format="xml" outputFile="${reports}/cpd.xml">
			<fileset dir="${src.dir}">
				<include name="**/*.java"/>
			</fileset>
		</cpd>
	</target>

	<target name="findbugs" depends="compile">
		<mkdir dir="${reports}"/>
		<findbugs home="${env.FINDBUGS_HOME}"
	              output="xml"
	              outputFile="${reports}/findbugs.xml"
	    	      jvmargs="-Xmx1024m">
			<sourcePath path="${src.dir}" />
			<class location="${classes}" />
		</findbugs>
	</target>

</project>

Las novedades que presenta son bastantes:

  • Configuro la propiedad environment para tener acceso a las variables de entorno.
  • Configuramos un nuevo directorio que albergará el resultado de los distintos análisis. Es el directorio que he llamado reports.
  • Defino las tareas Ant que se incluyen con PMD y FindBugs mediante la etiqueta taskdef, y buscando los jars a través de las variables de entorno.
  • Defino la tarea pmd indicando xml como formato de salida, el directorio que contiene el código fuente y el archivo de salida. PMD puede realizar análisis en base a un buen número de reglas. Podemos configurar las reglas que utilizaremos bien mediante etiquetas anidadas en la tarea Ant o mediante un archivo separado de reglas (lo que se indica en la tarea Ant como rulesetfiles). En mi caso he utilizado para probar la configuración que aparece bajo “Add some rule references to it” en la sección de crear un conjunto de reglas en la web de PMD. En el siguiente enlace podemos encontrar más información sobre la configuración de PMD.
  • Defino la cpd de forma muy parecida a la de pmd. Se indica xml como formato de salida, el directorio que contiene el código fuente y el archivo de salida. Para CPD no hay archivo de reglas. En el siguiente enlace se puede encontrar más información sobre la configuración de CPD.
  • Defino la tarea Ant para FindBugs. Además de directorio de fuentes y archivo y formato de salida, necesitamos indicarle el directorio de instalación de FindBugs y el directorio donde encontrar las clases compiladas ya que FindBugs las utiliza para su análisis. Por este último motivo declaramos la tarea de findbugs dependiente de la de compilación. Más información en el capítulo de tarea Ant de FindBugs.

Para la integración necesitaremos instalar algunos plugins para Hudson. Iremos al apartado de plugins dentro de la configuración de Hudson e instalaremos Static Analysis Utilities, PMD Plug-in, Duplicate Code Scanner Plug-in y FindBugs Plug-in.

Por último modificaremos la configuración de nuestra tarea Hudson. En la sección de “Acciones para ejecutar después” activaremos el visualizador de PMD, CPD y FindBugs. En la configuración de ant lanzaremos las tareas cleanReports, pmd, cpd y findbugs.

Tras mandar a Hudson que nos ejecute el proyecto obtendremos una salida similar a la siguiente:

y podremos ver detalles de nuestro análisis siguiendo los enlaces:

Hasta aquí esta entrada que seguro no será la última sobre Hudson, seguid atentos.

13 mayo 2010 at 12:25 pm 4 comentarios

Pequeña introducción a Git

Git es un sistema de control de versiones al igual que CVS, Subversion y otros.

Git fue diseñado por Linus Torwalds (creador de Linux) para utilizarlo en el desarrollo del núcleo de Linux. En su sección de descargas podemos encontrar entre otras, enlaces a versiones para Linux (en rpm o deb), MacOS y Windows (a través de Cygwin o del proyecto MSysGit que provee instalables completos e incluso una versión portable).

Si venimos desde un enfoque más clásico como CVS o Subversion, la principal diferencia que aporta Git es que es un sistema distribuido. ¿Y qué quiere decir distribuido?. Pues que a diferencia de CVS o Subversion podemos trabajar con nuestro control de versiones aunque no estemos conectados a una red, ya que es como si tuviésemos el servidor en nuestra propia máquina. De esta forma está diferenciado lo que son las acciones con nuestro repositorio y las que llevamos cabo con repositorios remotos (ese sería el estilo CVS).

git_1

En principio es una solución muy recomendable si queremos mantener un versionado en nuestra máquina de desarrollo (en este caso sólo utilizaremos los comandos entre desarrollo y el repositorio propio del esquema. Vamos a ver un pequeño resumen de los comandos que utilizaríamos en este caso.

  • Lo primero que necesitamos es configurar nuestro usuario:

    git config --global user.name "Don Nadie"
    git config --global user.email "don.nadie@test.com"

  • Para crear un repositorio nos situaremos en el directorio principal de nuestro proyecto (o en uno vacío si es un proyecto nuevo) y haremos:

    git init

    y si el proyecto está empezado añadiremos los archivos mediante

    git add .
    git commit -m "Mensaje" (Si no se le pasa -m nos pedirá un mensaje, ya que es obligatorio)

    con lo que ya tendremos todo nuestro proyecto bajo el control de versiones.

  • Para el ciclo de desarrollo normal, primero se añaden los cambios al índice (es como un almacén intermedio que almacena todos los cambios) y luego lo persistiremos en el repositorio.

    git add ruta/fichero Añade el fichero nuevo o modificado al índice
    git commit Persiste los cambios que tenemos en el índice al repositorio (nos pide mensaje)
    git commit -a Hace el paso al índice y el commit en un solo paso

  • Para ver el estado del desarrollo podemos utilizar los siguientes comandos:

    git status Muestra el estado de la rama de desarrollo
    git diff Muestra las diferencias entre la rama de desarrollo y el índice
    git diff --cached Muestra las diferencias entre el índice y el HEAD (último commit)
    git diff HEAD Muestra las diferencias entre la rama de desarrollo y el HEAD
    git log Nos muestra un historial de los commits del repositorio

  • El trabajo con ramas es muy sencillo en Git.

    git branch test Crea una rama de nombre “test” a partir de la actual
    git branch Nos muestra las ramas existentes y la rama en la que nos encontramos (cuando hacemos git status también nos muestra la rama en la que nos encontramos)
    git checkout test Nos sitúa en la rama test
    git merge test Si nos hemos situado en la rama master (la rama principal, en la que empezamos) nos combina los cambios en la rama test con esta rama

Git también tiene gran potencia para compartir el código con otros desarrolladores, aunque este caso lo dejaremos para otra entrada.

Por último no quisiera terminar esta entrada sin decir que Git no es el único control de versiones distribuido. También Mercurial o Bazaar nos pueden servir para los mismos fines e incluso pueden ser más sencillas si estamos acostumbrados a CVS.

3 septiembre 2009 at 8:10 pm Deja un comentario

Repositorios Maven: Nexus

Como dijimos en nuestra pequeña introducción a Maven, el lugar donde se va a almacenar nuestro software son los llamados repositorios.

509610_84209301_250

La distribución de Maven por defecto se descarga los artefactos del repositorio principal de Maven. Si bien esto a nivel personal es factible, cuando varios desarrolladores se tienen que descargar los mismos jars pesados una y otra vez es un despilfarro de ancho de banda considerable.

Por ello se suele instalar un repositorio propio. Podemos usar un servidor web sirviendo los directorios del repositorio pero no nos proporciona características muy deseables como son: ejercer de intermediario con otros repositorios, facilidades de navegación, facilidades de búsqueda o formularios para subir artefactos entre otras. Por ello existen otras soluciones que nos facilitan la vida, todas ellas libres y que son comparadas en esta matriz de comparación de gestores de repositorios Maven (Inglés en inglés).

Yo en su día probé Artifactory del que además tenemos esta guía de utilización de Artifactory. Sobre Archiva también he encontrado esta muy completa guía de utilización de Archiva (en tres partes II y III). Por eso (entre otras cosas) me he decidido a probar Nexus.

Nexus viene preparado para levantar un servidor y su instalación de esa manera está bien documentada en Maven: The definitive guide que es como nos recomiendan empezar en la web de Nexus. Pero yo quería aprovechar el Tomcat que tengo corriendo en mi servidor Xubuntu por lo que decidí instalar el war que se nos ofrece en la sección de descargas de Nexus. Los pasos que seguí son sencillos:

  • Descargué el war (nexus-1.1.1.war en ese momento) y lo renombré a nexus.war (para que la aplicación la despliegue como nexus y no nexus-1.1.1).
  • Desplegué el war a través de la aplicación manager de Tomcat.
  • Modifiqué el archivo plexus.properties dentro del directorio de la aplicación desplegada (en mi caso /usr/share/tomcat5.5/webapps/nexus/WEB-INF) para añadirle una ruta válida. Yo puse: nexus-work=/home/nexus/sonatype-works/nexus
  • Por último y aunque según la documentación no era necesario, añadí al script de arranque de Tomcat (/etc/init.d/tomcat5.5) la variable de entorno para indicarle el directorio de nexus. Al final de la línea que empieza por JAVA_OPTS se añade -DNEXUS_HOME=/home/nexus

Con esto y tras reiniciar el Tomcat, ya podemos apuntar nuestro navegador a la aplicación recién instalada (en mi caso http://server:port/nexus/). Podemos ver la página de Nexus que nos recibe:

nexus1_640

Sólo con esto ya podemos ver que Nexus nos va a proporcionar búsqueda de artefactos, así como algunas posibilidades de suscripción mediante RSS (por ejemplo a nuevos artefactos subidos). Para poder configurar Nexus, debemos identificarnos como administrador (“admin” con “admin123” por defecto). Lo primero que debemos configurar es:

  • Por seguridad modificar la contraseña del administrador (menú “Change Password”).
  • Configurar el servidor de correo (para correos de recuperación de contraseña). En el menú “Server” bajo “Administration”.
  • Habilitar el indexado de repositorios remotos. En el menú “Repositories” bajo “Administration”, pinchando sobre los repositorios de tipo proxy. Pondremos a true el campo “Download Remote Indexes” (Nexus se baja los índices de esos repositorios y puede tardar un rato). De esta manera podemos buscar artefactos que se encuentren en los repositorios remotos y descargarlos a nuestro repositorio

Finalmente tendríamos que configurar nuestro Maven local para que acceda a nuestro nuevo repositorio. Para ello introduciremos en el archivo de configuración de Maven (settings.xml en el directorio .m2 dentro de nuestro directorio personal) las líneas necesarias para reflejar nuestro repositorio:

    <mirror>
      <id>Nexus</id>
      <mirrorOf>central</mirrorOf>
      <name>Nexus Public Mirror.</name>
      <url>http://server:port/nexus/content/groups/public</url>
    </mirror>

Esto es todo por esta primera entrada sobre Nexus. En próximas entradas hablaré de algunas características de Nexus como son los grupos (fijaros ese groups en la ruta al repositorio en el código anterior) o la seguridad.

20 enero 2009 at 8:13 pm 1 comentario

Instalando Hudson sobre Tomcat en Ubuntu 8.04

En esta pequeña entrada voy a comentar los retoques que he tenido que hacer para conseguir instalar Hudson sobre Tomcat en mi XUbuntu 8.04 (estoy seguro de que en una Ubuntu es igual).
Hudson

Para empezar me descargué el war de la web de Hudson e instalé Tomcat a través de Synaptic (la versión que instala es la 5.5).

Quería desplegar Hudson a través de la aplicación de manager que viene con Tomcat, por lo que añadí un usuario con rol admin en /etc/tomcat5.5/tomcat-users.xml.

Entré en http://server:8180/manager/html (el puerto 8180 es con el que se ha instalado por defecto) y a través del formulario intenté desplegar el war (en la parte de “deploy” y “select war file to deploy”). Una rápida búsqueda en Google me llevó al problema (Inglés en inglés) y a la solución (Inglésen inglés): añadí al final de /etc/default/tomcat5.5:

TOMCAT5_SECURITY=no

Tras hacer esto (y tras reiniciar Tomcat como tras cada paso) Hudson se desplegó correctamente. Ahora sólo quedaba apuntar mi navegador a http://server:8180/hudson/ y esperar a que Hudson terminara su configuración. Pero de nuevo apareció otro error, en este caso de permisos. La solución estaba en el mismo lugar que la anterior, y esto fue lo que hice:

  • Cree el directorio /home/hudson y le puse de propietario tomcat55:nogroup el usuario con el que corre Tomcat por defecto. Además le di permisos rwxr-xr-x.
  • Edité el script para lanzar Tomcat (/etc/init.d/tomcat5.5) añadiendo en la parte que se define JAVA_OPTS: -DHUDSON_HOME=/home/hudson

Tras el último reinico, ¡por fin se terminó la instalación!. Ya podemos ver la página principal de Hudson.

hudson_3_640

Un poco vacía, pero ya la iremos llenando… ¿verdad?

10 noviembre 2008 at 9:25 pm 5 comentarios

Instalación de un servidor CVS casero

CVS (Concurrent Versions System) es un sistema de control de versiones, algo que no debería ser ajeno a ningún desarrollador.

En mi XUbuntu (todavía necesito las X para alguna cosilla, aunque estoy en proceso de quitarme) voy a instalar un servidor casero de CVS para mis cosillas. Voy a utilizar CVS porque es lo que más domino, aunque pretendo migrar a Subversion o Git más pronto que tarde. Cuando suceda, tendréis el correspondiente tutorial.

Lo primero que he hecho es instalar cvsd (es un recubrimiento a cvs para aumentar algo la seguridad), lo que nos instala cvs como dependencia. Durante la instalación nos pregunta los repositorios que queremos publicar mediante cvsd, aunque esto lo podemos modificar luego en el archivo cvsd.conf (en /etc/cvsd), más concretamente con las líneas que comienzan por Repos.

Para crear un repositorio (lógicamente los que le hemos indicado durante la instalación) utilizamos el comando init de cvs. Explicaros que cvs desde línea de comandos tiene la siguiente estructura:

cvs [cvs-options] cvs-command [command-options] [command-args]

El comando init inicializa un repositorio (lo ejecutaremos como root o mediante sudo). Mediante la opción -d le indicamos la ruta al repositorio.

cvs -d /var/lib/cvsd/tcymu init

Esto crea el repositorio en la ruta especificada, lo que podemos comprobar mirando el contenido de /var/lib/cvsd/tcymu. Observaremos el directorio CVSROOT con contenido propio del servidor CVS.

Ahora añadimos un usuario a nuestro repositorio (de nuevo como root):

cvsd-passwd /var/lib/cvsd/tcymu +tcymu

Nos pide un password, que será el que utilizaremos para entrar posteriormente. Lo almacena (cifrado por supuesto) en /var/lib/cvsd/tcymu/CVSROOT/passwd.

Bien, ya tenemos preparado el CVS. Si tenemos un firewall activado, debemos recordar abrir los puertos correspondientes: 2401 por defecto.

Y ahora y desde línea de comandos (es decir, que así podemos trabajar tanto en Linux como en Windows) podremos identificarnos en CVS mediante el comando:

cvs -d :pserver:user@server:/repository login

Hay que notar que la opción -d sólo es necesaria si no tenemos definida una variable de entorno CVSROOT. Por lo tanto si trabajamos con un único servidor CVS pues lo más cómodo es añadir dicha variable de entorno.

Una vez identificados en CVS el primer paso sería añadir un directorio al CVS, ya que de momento nuestro repositorio está vacío. Creamos un directorio local que albergará nuestro proyecto CVS y dentro de ese directorio ejecutamos:

cvs -d :pserver:user@server:/repository co -l .

Notaremos que se nos ha creado una carpeta CVS que contiene los archivos necesarios para mantener el estado de nuestra imagen del CVS.

Ahora ya podemos empezar a trabajar en nuestro proyecto de la forma habitual. Crearemos archivos, los añadiremos, haremos commit y demás. El trabajo habitual con CVS queda para una entrada futura, aunque no faltan precisamente recursos en la red.

15 octubre 2008 at 7:28 pm Deja un comentario


Mi perfil

View Miguel Orbegozo's profile on LinkedIn

Feedjit

Feeds

Otros…

BlogESfera Directorio de Blogs Hispanos - Agrega tu Blog

Bitacoras.com

Add to Technorati Favorites