[Gvsig_desarrolladores] Dependencia geoapi no encontrada

Fernando González fergonco en gmail.com
Mar Abr 12 14:28:06 CEST 2011


Vale, funciona. He conseguido crear un main que lee un DBF y un DXF.
Ahora voy a ver si voy comprendiendo cosas, simplificando otras, etc.
Cuando tenga claro el tema envío mis resultados y las dudas que me
hayan quedado a la lista por si a alguien le es de utilidad.


2011/4/12 Cèsar Ordiñana <cordinyana en gvsig.com>:
> 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)
>
> _______________________________________________
> gvSIG_desarrolladores mailing list
> gvSIG_desarrolladores en listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores
>


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