[Gvsig_desarrolladores] Dependencia geoapi no encontrada

Jorge Piera Llodrá jpiera en prodevelop.es
Mar Abr 12 12:23:21 CEST 2011 

Hola de nuevo.

Los "managers" se registran en los "locators" mediante las "libraries". 
Hemos creado una clase 
org.gvsig.tools.library.impl.DefaultLibrariesInitializer que se puede 
utilizar para incializar todas las librerías de tu aplicación, de forma 
que no lo tengas que hacer manualmente tal y como lo estás tratando de 
hacer. Si lo que estás haciendo es un test unitario, puedes heredar de 
org.gvsig.tools.junit.AbstractLibraryAutoInitTestCase, que ya se encarga 
de incializar las librerías automáticamente.

Un pequeño detalle: por razones históricas hay proyectos de gvSIG que no 
tienen estructura de proyecto de maven. Si tienes uno de esos proyectos 
en tu workspace de Eclipse, tienes que generar el proyecto de Eclipse 
mediante el comando "mvn -P eclipse-project" en lugar de con el "mvn 
eclipse:eclipse". Si no lo haces así, al ejecutar los tests unitarios el 
Eclipse no encontrará los recursos del proyecto donde se definen las 
librerías que implementan el interfaz Library y será imposible 
inicializarlas.

Un saludo,
Jorge.


On 04/12/2011 12:07 PM, Fernando González wrote:
> Bueno, parece que me voy cogiendo al tema de los classifiers de maven
> (sois unos "cebaos" de maven xD). Es impresionante el curro que hay
> hecho.
>
> A ver, ahora tengo este código[1] que compila, pero que al ejecutar me
> da la siguiente excepción en la última línea:
>
>
> Exception in thread "main" java.lang.NullPointerException
> 	at org.gvsig.fmap.geom.impl.DefaultGeometryLibrary.doPostInitialize(DefaultGeometryLibrary.java:96)
> 	at org.gvsig.tools.library.AbstractLibrary.postInitialize(AbstractLibrary.java:175)
> 	at org.test.App.main(App.java:40)
>
>
> básicamente porque ToolsLocator.getDataTypesManager() devuelve un
> null. De hecho ningún "locator" es capaz de devolverme un "manager"
> que no sea distinto de nulo.
>
> Por cierto, este problema lo resolví la vez que intentamos integrar
> GearScape y gvSIG (hace cosa de 2-3 años), pero no sé dóned puse el
> código y no consigo acceder al plone para investigar los mensajes que
> dejé allí. Imagino que mi usuario habrá caducado.
>
> Un saludo.
>
> [1]
>
> 		DALFileLibrary libFile = new DALFileLibrary();
> 		libFile.initialize();
> 		DefaultGeometryLibrary defGeomLib = new DefaultGeometryLibrary();
> 		defGeomLib.initialize();
>
> 		ProjectionLibrary projLib = new ProjectionLibrary();
> 		projLib.initialize();
>
> 		CresquesCtsLibrary cresquesLib = new CresquesCtsLibrary();
> 		cresquesLib.initialize();
>
> 		DBFLibrary dbfLibrary = new DBFLibrary();
> 		dbfLibrary.initialize();
>
> 		JTSIndexLibrary jtsIndex = new JTSIndexLibrary();
> 		jtsIndex.initialize();
>
> 		defGeomLib.postInitialize();
>
>
> 2011/4/11 Cèsar Ordiñana<cordinyana en gvsig.com>:
>    
>> El 11/04/11 14:39, Fernando González escribió:
>>      
>>> Hola, necesito leer un dxf en un proyecto y he pensado en usar las
>>> librerías de gvSIG. Me he creado un pom[3] pero no sé si estoy tirando
>>> del repositorio correcto[1] y de las versiones correctas de gvSIG[2].
>>>
>>> El caso es que me fallan estas dependencias:
>>>
>>>        1) org.test:dxftest:jar:1.0-SNAPSHOT
>>>        2) org.gvsig:org.gvsig.dxf:jar:2.0-SNAPSHOT
>>>        3) org.gvsig:org.gvsig.projection:jar:2.0-SNAPSHOT
>>>        4) org.opengis:geoapi:jar:2.0
>>>
>>>        1) org.test:dxftest:jar:1.0-SNAPSHOT
>>>        2) org.gvsig:org.gvsig.dxf:jar:2.0-SNAPSHOT
>>>        3) org.gvsig:org.gvsig.projection:jar:2.0-SNAPSHOT
>>>        4) javax.media:jai_core:jar:1.1.3
>>>
>>>        1) org.test:dxftest:jar:1.0-SNAPSHOT
>>>        2) org.gvsig:org.gvsig.dxf:jar:2.0-SNAPSHOT
>>>        3) org.gvsig:org.gvsig.projection:jar:2.0-SNAPSHOT
>>>        4) javax.media:jai_codec:jar:1.1.3
>>>
>>>
>>> ¿Están mal configuradas las dependencias o el problema es mío?
>>>        
>> Hola Fernando,
>>
>> En el site del proyecto projection puedes ver sus dependencias y de qué
>> repositorios salen (apartado Dependency Repository Locations):
>>
>> http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/docs/reference/org.gvsig.projection/2.0.0/dependencies.html
>>
>> Justo esas dependencias que no encuentra (geoapi, jai_core y jai_codec)
>> están en el repositorio maven de osgeo. Entiendo que debería haberlas
>> encontrado también, ya que las dependencias llevan también el
>> repositorio. En cualquier caso creo que se arreglará añadiendo esta
>> entrada dentro de<repositories>:
>>
>> <repository>
>> <id>osgeo</id>
>> <name>Open Source Geospatial Foundation</name>
>> <url>http://download.osgeo.org/webdav/geotools</url>
>> <releases>
>> <enabled>true</enabled>
>> <updatePolicy>never</updatePolicy>
>> <checksumPolicy>warn</checksumPolicy>
>> </releases>
>> <snapshots>
>> <enabled>false</enabled>
>> </snapshots>
>> </repository>
>>
>> Por otro lado, en ejecución no te funcionará tal cuál lo tienes, ya que
>> la librería de DXF depende sólo del API de proyecciones en compilación,
>> necesitarás incluir una implementación de proyecciones en ejecución.
>>
>> Para simplificar este tipo de cosas de cara a tests unitarios o clases
>> de pruebas, hemos preparado un pom.xml que incluye todas las librerías
>> de gvSIG necesarias para ejecución. Se puede usar de dos formas
>> complementarias, según lo que queramos hacer:
>>
>> - Queremos usar las mismas versiones que se usan en gvSIG, tanto de las
>> librerías de gvSIG como de sus dependencias.
>>
>>    Incluimos lo siguiente en nuestro pom.xml:
>>
>> <dependencyManagement>
>> <dependencies>
>> <dependency>
>> <groupId>org.gvsig</groupId>
>> <artifactId>org.gvsig.core.maven.dependencies</artifactId>
>> <version>2.0.1-SNAPSHOT</version>
>> <type>pom</type>
>> <scope>import</scope>
>> </dependency>
>> </dependencies>
>> </dependencyManagement>
>>
>>    Esto hace que todo el apartado<dependencyManagement>  que hay en
>> org.gvsig.core.maven.dependencies se incluya dentro del nuestro. Para el
>> que no lo sepa, el apartado dependencyManagement sirve para fijar las
>> versiones de las dependencias, por lo que ya no hace falta definirlas
>> dentro del apartado<dependency>.
>>
>>    Si haces lo anterior, al incluir la dependencia con DXF no tendrás
>> que poner la versión. Quedará tal que así:
>>
>>         <dependencies>
>>                 ...
>>                 <dependency>
>>                         <groupId>org.gvsig</groupId>
>>                         <artifactId>org.gvsig.dxf</artifactId>
>>                         <scope>compile</scope>
>>                 </dependency>
>>
>>         </dependencies>
>>
>>
>>    Verás que he añadido también:<scope>compile</scope>. Esto es porque
>> el pom de org.gvsig.maven.core.dependencies tiene todas las dependencias
>> configuradas para ejecución, si las necesitas de compilación hay que
>> indicarlo
>>
>>
>> - Queremos tener todas las dependencias de ejecución necesarias para
>> nuestro proyecto:
>>
>>    Para ello incluiremos la siguiente dependencia dentro del apartado
>> <dependencies>:
>>
>> <dependency>
>> <groupId>org.gvsig</groupId>
>> <artifactId>org.gvsig.core.maven.dependencies</artifactId>
>> <version>2.0.1-SNAPSHOT</version>
>> <type>pom</type>
>> <scope>runtime</scope>
>> </dependency>
>>
>>    Si es sólo para tests unitarios se puede cambiar el scope runtime por
>> test.
>>
>>    Con esto heredaremos todas las dependencias de ejecución, incluyendo
>> todas las librerías del core y sus dependencias. La primera vez, sino
>> has compilado gvsig por tu cuenta, se bajará un montón de librerías,
>> pero te despreocupas del tema.
>>
>> Si tienes una aplicación que usa libDXF, para su ejecución en producción
>> si que te recomiendo que revises qué dependencias específicas necesitas
>> para incluirlas individualmente. Además hay casos en los que podrás
>> elegir la implementación. Por ejemplo, del api de proyecciones hay
>> varias implementaciones disponibles, ej: la de org.gvsig.projection
>> mismo o la de org.gvsig.crs.
>>
>> Saludos,
>>
>> --
>> Cèsar Ordiñana Navarro
>> gvSIG software architect
>> DiSiD Technologies (http://www.disid.com)
>>
>> _______________________________________________
>> gvSIG_desarrolladores mailing list
>> gvSIG_desarrolladores en listserv.gva.es
>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>>
>>      
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>    


-- 
Jorge Piera Llodrá
gvSIG Development Team
PRODEVELOP
Plaza Don Juan de Villarrasa, 14 - 5
46001 Valencia
Tel: +34 963510612
Fax: +34 963510908
e-mail: jpiera en prodevelop.es
http://www.prodevelop.es
http://www.gvsig.org

Más información sobre la lista de distribución gvSIG_desarrolladores