[Gvsig_desarrolladores] Dependencia geoapi no encontrada

Cèsar Ordiñana cordinyana en gvsig.com
Mar Abr 12 14:02:42 CEST 2011


Como comenta Jorge, no hace falta que inicialices tú las librerías, 
basta con que tengas esto en el arranque de tu aplicación, que se 
encarga de buscarlas todas e inicializarlas:

     import org.gvsig.tools.library.impl.DefaultLibrariesInitializer;
     ...

     new DefaultLibrariesInitializer().fullInitialize();

Y si es un test, como dice Jorge puedes heredar de la clase 
AbstractLibraryAutoInitTestCase que ya hace el paso anterior. Si la usas 
tienes que incluir la dependencia con:

<dependency>
<groupId>org.gvsig</groupId>
<artifactId>org.gvsig.tools.lib</artifactId>
<type>test-jar</type>
</dependency>

Saludos,

El 12/04/11 12:23, Jorge Piera Llodrá escribió:
> 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)
>>>

Saludos,

-- 
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)



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