Bicosyes - since evermore… » Subversion en aplicaciones Java desde Ubuntu

Subversion en aplicaciones Java desde Ubuntu

Publicado por blaxter - 15 Ene 2008 a las 19:09

Cualquiera que haya usado Java, tanto usuarios como desarrolladores, habrán tenido múltiples problemas debido al tipico problema del classpath y derivados. Es posiblemente uno de los (múltiples) principales problemas de Java. Y no será por soluciones adoptadas en otras ámbitos ampliamente usadas y aceptadas como válidas. Pero bueno, ese es otro debate.

Para poder interactuar con subversion desde aplicaciones Java necesitas la librería cliente JavaHL, ésta puede ser instalada fácilmente usando los paquetes de tu distro, en Ubuntu:

$ sudo aptitude install libsvn-java

Pero a pesar de esto, tus aplicaciones Java seguirán sin "encontrarla", necesitas indicar en tu comando de ejecución de cientos de caracteres de tu aplicación el siguiente parámetro:

-Djava.library.path=/usr/lib/jni

Obviamente /usr/lib/jni es donde está la librería (el .so), quizá en otras distros no-ubuntu sea diferente.

En mi caso particular lo necesitaba para subclipse en Aptana, en cuyo caso hay que añadir esa opción al AptanaStudio.ini donde están los parámetros usados al arrancar Aptana.

En Linux, Software |

6 Comentarios »

RSS feed para los comentarios de esta entrada.

Por lo que he visto, parece que maven soluciona esos problemas.

Le dices de qué librerías dependes y te las baja de internet antes de compilar.
No he tenido ocasión de testearlo, pero me pareció cómodo.

De hecho en proyectos compartidos, no hace falta subir al repositorio las librerías, ni instalarlas en el sistema. Maven descarga las versiones necesarias.

Y tiene compatibilidad con eclipse

Comentario por GoLo — 15 Enero, 2008 @ 20:25 #
Pero maven no es lo mismo que un cpan/pear/gems/apt-get/*, maven es para desarrollo y empaquetamiento. Es decir no sirve al usuario final, si por ejemplo ahora pillas un programa en ruby y lo ejecutas te podría decir “gema json no encontrada” y haces gem install json, lo mismo con pear (php) o cpan (perl) o lo mismo en apt-get/aptitude para software en general.

maven no es para eso, es más limitado, ahora puedo ejecutar un programa java y me dice “no encuentro librería churrosConChocalate”, para descargarla tendría que tener el pom.xml o hacerlo a mano, aparte de conocer en profundidad el funcionamiento de maven, su ciclo de vida, blablameaburroblabla… vamos que son cosas similares, pero distintas.

Comentario por blaxter — 15 Enero, 2008 @ 23:56 #
Hola:

Lo de maven es cierto y funciona bien para librerías .jar que estén en algún repositorio de maven en internet -casi todas las gratuitas lo están-.

Sin embargo, para librerías nativas estilo .dll o .so, eso no vale. Supongo que no queda más remedio que meterlas en una variable de esas -Djava.library.path…

Se bueno.

Comentario por chuidiang — 15 Enero, 2008 @ 23:58 #
@chuidiang, el problema de Java en general es que no tiene una forma unificada para distribuir y localizar todas las librerías (.jar) como sucede en otro lenguajes. Maven sirve para la etapa de desarrollo, pero nada más. (ponte a decirle a un supuesto usuario que se cree un descriptor de proyecto, balbalbalba…)

Comentario por blaxter — 16 Enero, 2008 @ 17:19 #
XD Owned

De hecho, para algunas cosas medio-flexibles me he tenido que pelear con Class Loaders.

Comentario por GoLo — 16 Enero, 2008 @ 19:40 #
Es que en esto java deja mucho que desear, además de tener que meter en la ejecución el classpath con la ruta a todos los “.jar” uno por uno (eso sí que es la leche, menos mal que existen cosas como Ant, Eclipse y demás que lo automatizan, porque si no …)

Comentario por Fran — 20 Enero, 2008 @ 13:33 #