Integrando herramientas en Eclipse

Estoy tratando de uniformar mi entorno para desarrollo Java (y eventualmente otros lenguajes) con Eclipse y unos cuantos plugins. Hasta el momento tengo elegidos:

1) Eclipse IDE for Java Developers (mejor que la edición para Java empresarial, es “más configurable”)

2) Subclipse, para conectar a Subversion (por el momento es suficiente, en algún momento evaluaré el cambio a Bazaar o Mercurial).

3) Apache Ivy, para gestión de dependencias (no me convence Maven, porque siento que hace muchas cosas). Pendiente: investigar como crear mi propio repositorio público.

4) TestNG, para pruebas automáticas (JUnit no me gusto al principio, y después ya fue tarde, TestNG es mucho más fácil de usar).

5) Hudson-eclipse, para conectar con Hudson (por el momento sólo lo tengo instalado).

6) Findbugs, para analizar estáticamente el código fuente (además de PMD y Checkstyle, pero todavía no me decido a mantenerlos).

Adicionalmente, tengo instalados VisualSVN (distribución de Subversion para Windows, que permite delegar la autenticación al dominio), Ant 1.8 (en Eclipse: Preferences -> Ant -> Runtime: Ant Home, permite cambiar la ubicación del Ant usado para compilar los proyectos. En Hudson: Administrar Hudson -> Configurar Sistema -> Ant: Añadir Ant, eventualmente deseleccionar la opción de descarga) y Tomcat6 (donde instale Hudson).

Visualizo algunos “problemas” de integración (que podrían no ser tales):

1. Ant con Eclipse y con Hudson. La idea es utilizar el mismo build.xml para Eclipse, Hudson (y eventualmente, la linea de comandos si fuera necesario).
2. Apache Ivy con Hudson e Ivy con Eclipse, la misma idea anterior, mantener sólo un Ivysettigs.xml y sólo un Ivy.xml por proyecto Eclipse (que además debería ser el mismo que use Hudson para el build).

Por el momento, tanto Eclipse como Hudson permiten utilizar un IvySettigs.xml centralizado (En Eclipse, Preferences -> Ivy -> Settings: Ivy Settings Path; en Hudson, (estando instalado el plugin respectivo), Administrar Hudson -> Configurar el sistema -> Ivy: Ivy Setting: Settings File) . Tengo que ver lo de los proyectos, y como engancho con ANT. A medida que vaya realizando esto, voy actualizando este post.

Actualización: Ivy tiene problemas con TestNG, porque este último no cumple el patrón de nombres esperado ([artifact]-[revision].[ext]). Por ahora, no queda otra que agregar la dependencia manualmente en Eclipse.

Compilación Nativa de PL/SQL

Al intentar compilar un package PL/SQL en forma nativa me salio el siguiente error:

Warning: Package created with compilation errors

show errors
Errors for PACKAGE TEST_PG
LINE/COL ERROR——– —————————————————————–
0/0 PLS-00920: parameter plsql_native_library_dir is not set

Esto indica que falta configurar algunos parámetros:

• plsql_native_make_file_name: Indica donde reside el makefile para crear shared librarys (habitualmente $ORACLE_HOME/plsql). No es asignado por default, y debe ser seteado vía alter system. Por ejemplo si ORACLE_HOME=/u01/app/oracle/product/9.2.0, hay que ejecutar (como DBA):

        ALTER SYSTEM SET plsql_native_make_file_name = '/u01/app/oracle/product/9.2.0/plsql/spnc_makefile.mk';

• plsql_native_make_utility: Indica donde esta el utilitario make. Idem. caso anterior debe ser seteado vía alter system. Por ejemplo en Solaris:

        ALTER SYSTEM SET plsql_native_make_utility='/usr/ccs/bin/make';

• plsql_native_library_dir: Indica el directorio “destino” de las shared librarys. El usuario ‘oracle’ debe tener permiso de escritura y sólo root y oracle deberían ser capaces de esccribir y/o eliminar archivos en dicho directorio (que debe existir antes de setear el directorio vía alter system)

        ALTER SYSTEM SET plsql_native_library_dir = '/u01/app/oracle/product/9.2.0/plsql_libs';

• plsql_native_c_compiler: Indica la ruta completa del compilador de C (debería setearse en el makefile). Por ejemplo en el archivo spnc_makefile.mk:

  # Specify C Compiler

  #

  CC=/opt/SUNWspro/bin/cc

• plsql_native_c_linker: Indica la ruta completa del enlazador (debería setearse en el makefile). Por ejemplo en el archivo spnc_makefile.mk:

  # Specify C Compiler

  #
        LD=/usr/ccs/bin/ld

Los últimos parámetros deberían setearse sólo si son distintos de los suministrados por defecto por el sistema operativo. Finalmente el modo de compilación se setea vía alter session por lo que no es necesario modificar el default (INTERPRETED).