![[ Puerto Cero Uno ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiXs7hWiiK0_ETMqSqjEYdPtKVGAtAw_S16cM3u-3t1kwYIw-FM1aSQeOkrlr9lmqom-9Kw9kz0ZoPNXfpYGC_CIbLwn20L7Ps3leRsUpjPp63xioaYTeMLJsI-2JnRc8mWwH76Jbhn-jx/s752/puertocerounobanner.jpg)
Adaptar la configuración por defecto
Ivy está preconfigurado por defecto, de manera que facilita su utilización en un entorno sencillo. En este tutorial, cercano a una documentación de referencia, explicaremos la configuración por defecto y cómo poder ajustarla a nuestra necesidad. Para profundizar en dichos parámetros de configuración y lo que permiten hacer, es recomendable además leer los siguentes tutoriales: Multiple Resolvers y Dual Resolver o bien la documentación Ivy de referencia Settings Files.Concepto
La configuración por defecto incluye 3 tipos de repositorio:- local: repositorio privado para el usuario.
- shared: repositorio compartido por los miembros del equipo.
- public: el repositorio en el que se encuentran la mayoria de los modulos, especialmente aquellos que dependen de terceros.
Local
Un repositorio local es especialmente útil cuando queremos aislar lo que realizamos del resto de cambios que suceden en el entorno. Esto implica que, cada vez que Ivy encuentra un módulo en el repositorio, éste es el que se usara aunque no esté disponible para el resto. Por ejemplo, si tenemos un módulo que tiene una dependencia con el módulo foo en la revisión de latest.integration, si dicha revisión de foo se encuentra en el repositorio local, esta es la que se utilizará para resolver la depencia, aún cuando exista una revisión más reciente en otro repositorio. Esto puede causar algún problema, pero supongamos que necesitamos implementar una nueva funcionalidad en el proyecto, y para realizarlo hemos de modificar dos modulos: añadir un método en foo y realizar una llamada desde el módulo bar. En este caso si publicamos foo en nuestro repositorio local, estaremos seguros de que dichas modificaciones seran tenidas en cuenta dentro del modulo bar, aún cuando algún otro miembro publique una nueva revision de fooen el repositorio shared (sin que dicha revision tuviese en cuenta nuestras modificaciones). Tenemos que tener cuidado de limpiar el repositorio local una vez una vez terminadas y publicadas en sharedlas modificaciones, lo que nos actualizará el repositorio local con todas las modificaciones publicadas por el equipo en shared. Tengamos en cuenta además que todos los modulos que se encuentran en local deben tener resueltas todas sus dependencias, p.ej. su descriptor de modulo y los artefactos publicados.Shared
Como nos indica su nombre, el repositorio shared, esta concebido para compartirse entre los miembros del equipo de desarrollo. Es donde se publica todos los módulos privados del equipo y donde se encuentran modulos que no son accesibles en el repositorio public(supongamos modulos utilizados internamente, o utilidades, sun., ibm. jars, por ejemplo). Es posible que en shared encontremos modulos que sean inconsistentes para un repositorio public(descriptores de modulo incompletos, p-ej). Los modulos pueden repartirse entre el repositorio shared y el public: Por ejemplo, podemos tener un descriptor de modulo en el repositorio shared y sus artefactos en publicPublic
El repositorio public, es el lugar donde se encuentra la mayoria de modulos, carecen sin embargo de la información necesaria (javadoc, etc...). Normalmente es un repositorio accesible a través de internet, aunque esto no sea un requisito.Configuración de los repositorios
Ahora que hemos visto el funcionamiento de cada uno de los 3 repositorios, veamos como se configuran según necesitamos. Primero, existen varios repositorios usan la misma raíz en nuestro sistema de ficheros. Referenciado a través de ${ivy.default.ivy.user.dir}, esta es la ruta del directorio .ivy2 en nuestro user home. sobreescribir los settings por defecto que Ivy incluye en su jar. Si queremos modificarlas sin declarar nuestro propio fichero de configuración ivysettings.xml lo podemos hacer:- Establecer una property de Ant antes de cada llamada a Ivy en el fichero build.xml si utilizamos Ivy desde Ant
- Establecer una variable de entorno en el sistema si utilizamos Ivy desde la linea de comandos
A continuación, mostramos como sobre escribir los valores por defecto de los distintos repositorios y cuales son sus valores por defecto, para cada uno de ellos
<target name="resolve">
<property name="ivy.default.ivy.user.dir" value="/path/to/ivy/user/dir"/>
<ivy:resolve />
</target>
Local
Por defecto, el repositorio local se encuentra en ${ivy.default.ivy.user.dir}/local. Esto es comunmente un buen lugar, pero es posible que deseemos modificarlos.ivy.local.default.root. Ejemplo:
ivy.local.default.root=/opt/ivy/repository/localSi tenemos un directorio que deseamos usar como local, podemos configurar los parametros para ello a través de las siguientes variables:
ivy.local.default.ivy.patternproporciona un patron para identificar los ficheros ivy.
ivy.local.default.artifact.patternproporciona un patron para identificar artefactos.
Por ejemplo:
ivy.local.default.root=/opt/ivy/repository/local
ivy.local.default.ivy.pattern=[module]/[revision]/ivy.xml
ivy.local.default.artifact.pattern=[module]/[revision]/[artifact].[ext]
Shared
El repositorio shared, se encuentra en la ruta que indica ${ivy.default.ivy.user.dir}/shared. Esto es apropiado si no estamos trabajando dentro de un equipo, lo cual le quita su valor. Así que lo más común es reconfigurarlo para que sea accesible al resto del grupo.Podemos utilizar la variable
ivy.shared.default.rootpara indicar otra ruta. Además, es posible configurar como ha de ser la estructura de dicho repositorio a través de patrones, mediante las variables:
ivy.shared.default.ivy.patternpatron para encontrar los ficheros ivy.xml
ivy.shared.default.artifact.patternpatron para encontrar los artefactos
Por ejemplo:
ivy.shared.default.root=/opt/ivy/repository/shared
ivy.shared.default.ivy.pattern=[organisation]/[module]/[revision]/ivy.xml
ivy.shared.default.artifact.pattern=[organisation]/[module]/[revision]/[artifact].[ext]
Public
El repositorio public es el que apunta la variable maven public repository, cuando trabajamos con la configuración de compatibilidad Maven 2. Este repositorio tiene la ventaja de contener la mayoría de modulos y sus descriptores, documentación, etc... La calidad de estos metadados noes siempre la más correcta, pero sí un buen comienzo, para utilizar una herramienta como Ivy para la resolución de dependencias transitivas. Además de la facilidad de uso que ofrece, es recomendable leer Best practices para tener un buen conocimiento de ventajas e inconvenientes, a la hora de usar un repositorio public, antes de crear uno propio en un entorno de producción. En la versión 1.4 de Ivy se utilizaba ivyrep como resolver por defecto, si queremos reestablecer esta configuración, hemos de crear la property ivy.14.compatible=true en el fichero build de antProfundizar en Ivy
Además de las configuracion de repositorios en un sistema de ficheros local, podemos encontrarnos con un requisito, que establezca el acceso a shared en un servidor Web. O bien, modificar el uso de un repositorio public de maven 2. Todo esto puede hacerse mediante configuración. Expliquemos primero la estructura de ivysettings.xml que se encuentra dentro del jar de Ivy .ivysettings.xml
<ivysettings>No obtenemos mucha información, ya que la configuración se reparte entre los distintos ficheros referenciados por include. Esto nos permite modificar ciertas partes sin afectar al resto.
<settings defaultResolver="default"/>
<include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>
Por ejemplo, si deseamos declarar nuestro propio resolver, lo configurariamos de la siguiente manera:
<ivysettings>
<settings defaultResolver="default"/>
<include url="http://myserver/ivy/myivysettings-public.xml"
<include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>
Solo hemos de modificar el fichero ivysettings-public.xml para añadir nuestro propio resolver. Tengamos en cuenta además que esto puede realizarse ya que conocemos donde apunta la variable ${ivy.default.settings.dir} (p-ej. la que tiene configurada por defecto en el jar). Para finalizar, hemos de modificar el fichero ivysettings que hemos referenciado, el cual se ecuentra en la dirección http://myserver/ivy/myivysettings-public.xml para declarar nuestro propio resolver publico.
Un ejemplo:
<ivysettings>
<resolvers>
<filesystem name="public">
<ivy pattern="/path/to/my/public/rep/[organisation]/[module]/ivy-[revision].xml" />
<artifact pattern="/path/to/my/public/rep/[organisation]/[module]/[artifact]-[revision].[ext]" />
</filesystem>
</resolvers>
</ivysettings>
El ultimo paso que debemos realizar para que el resto de configuracion sea tenida en cuenta es modificar los ficheros incluidos en ivysettings.xml:
ivysettings-public.xml
<ivysettings>
<resolvers>
<ibiblio name="public" m2compatible="true"/>
</resolvers>
</ivysettings>
ivysettings-shared.xml
<ivysettings>
<property name="ivy.shared.default.root" value="${ivy.default.ivy.user.dir}/shared" override="false"/>
<property name="ivy.shared.default.ivy.pattern" value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" override="false"/>
<property name="ivy.shared.default.artifact.pattern" value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" override="false"/>
<resolvers>
<filesystem name="shared">
<ivy pattern="${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern}" />
<artifact pattern="${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}" />
</filesystem>
</resolvers>
</ivysettings>
ivysettings-local.xml
<ivysettings>
<property name="ivy.local.default.root" value="${ivy.default.ivy.user.dir}/local" override="false"/>
<property name="ivy.local.default.ivy.pattern" value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" override="false"/>
<property name="ivy.local.default.artifact.pattern" value="[organisation]/[module]/[revision]/[type]s/[artifact].[ext]" override="false"/>
<resolvers>
<filesystem name="local">
<ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" />
<artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" />
</filesystem>
</resolvers>
</ivysettings>
ivysettings-main-chain.xml
<ivysettings>
<resolvers>
<chain name="main" dual="true">
<resolver ref="shared"/>
<resolver ref="public"/>
</chain>
</resolvers>
</ivysettings>
ivysettings-default-chain.xml
Esto nos da una idea de las posibles configuraciones que permite Ivy para adaptarla a nuestras necesitades.
<ivysettings>
<resolvers>
<chain name="default" returnFirst="true">
<resolver ref="local"/>
<resolver ref="main"/>
</chain>
</resolvers>
</ivysettings>
Buen desarrollo!
