[Gvsig_desarrolladores] Dependencia geoapi no encontrada

Fernando González fergonco en gmail.com
Lun Abr 18 13:39:05 CEST 2011


No había caído en el tema de las exclusiones y precisamente lo estoy
usando para que no me traiga una JTS distinta a la que ya estoy
usando.

De momento lo dejo como está y cuando tenga que terminar el proyecto
le meto las exclusiones. Con suerte estará DAL como multimódulo y me
las ahorro.

Gracias!

2011/4/18 Cèsar Ordiñana <cordinyana en gvsig.com>:
> El 14/04/11 15:36, Fernando González escribió:
>> César, gracias por los comentarios. También me funciona con tu sugerencia.
>>
>> Resumiendo, hay que depender de las APIs en tiempo de compilación y de
>> las implementaciones en tiempo de ejecución (runtime) ¿no?
>
> Si, eso es.
>
>> Ahora tengo una pregunta para nota. Supongo que en el contexto de
>> gvSIG no es un problema, pero en mi caso sí que puede serlo. Si tomo
>> tu pom tal cual, las dependencias hacen 35M. He reemplazado la
>> dependencia a org.gvsig:org.gvsig.core.maven.dependencies por
>> dependencias individuales sólo a las implementaciones que necesito[1]
>> y he podido reducirlo a 18M.
>>
>> Teniendo en cuenta que yo no voy a dibujar ni proyectar el DXF,
>> ¿existe la posibilidad de reducir las dependencias necesarias? Intuyo
>> que podría crearme yo mis implementaciones "vacías" de simbología y
>> "proyecciones". Tiene pinta de que me vaya a conformar con aumentar 18
>> Mb el tamaño de mi aplicación pero me interesa saber si es posible.
>
> Si, se puede reducir quitando alguna dependencia. El problema con los
> proyectos con estructura vieja es que, aunque generan varios jars, el
> pom.xml es el mismo para todos y, por tanto, las dependencias.
>
> Por ejemplo, en el caso del proyecto org.gvsig.fmap.dal.file
> (libFMap_dalfile) se generan varios jars, uno general más uno por cada
> proveedor (shp, dbf, dxf y dgn). Además, para dxf y dgn se generan un
> par de jars más que incluyen operaciones para cargar la leyenda.
>
> En realidad sólo estos jars son los que dependen de
> org.gvsig.symbology.lib.api, pero como el pom.xml es el mismo para
> todos, el resto se la llevan detrás.
>
> El día que convirtamos DAL en un proyecto multimódulo se solventará
> esto. Mientras, puedes aprovechar las opciones de maven que te permiten
> excluir dependencias transitivas (tag <exclusions>). Te pongo como
> quedaría la lista de dependencias en tu proyecto para que veas como
> sería. En concreto he excluido las dependencias con
> org.gvsig.fmap.mapcontext y org.gvsig.symbology.lib.api. Fíjate también
> en que hay que ponerlo, tanto en la dependencia con
> org.gvsig.fmap.dal.file como con org.gvsig.fmap.dal.file:store.dxf, ya
> que en realidad son el mismo pom:
>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>3.8.1</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.tools.lib</artifactId>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.metadata.lib.basic.api</artifactId>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.dal</artifactId>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.dal</artifactId>
> <classifier>spi</classifier>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.dal.file</artifactId>
> <classifier>store.dxf</classifier>
> <scope>compile</scope>
> <exclusions>
> <exclusion>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.mapcontext</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.symbology.lib.api</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.geometry</artifactId>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.projection</artifactId>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.compat</artifactId>
> <classifier>se</classifier>
> <scope>runtime</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.geometry</artifactId>
> <classifier>impl</classifier>
> <scope>runtime</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.projection</artifactId>
> <classifier>cresques-impl</classifier>
> <scope>runtime</scope>
> </dependency>
> <dependency>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.dal.file</artifactId>
> <scope>runtime</scope>
> <exclusions>
> <exclusion>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.fmap.mapcontext</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.gvsig</groupId>
> <artifactId>org.gvsig.symbology.lib.api</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
>
> Espero que con esto se te reduzcan un poco las dependencias. No se si se
> podría quitar algo más si existen más funcionalidades que no vayas a
> usar. Mediante la orden "mvn dependency:tree" puedes ver cuál es el
> árbol de dependencias de tu proyecto y seguir investigando a ver.
>
> De proyecciones no creo que puedas huir porque se necesita para la
> generación de la proyección con la que se carga el DXF, aunque no uses
> reproyección. Lo que no se es si se podrá quitar alguna de sus dependencias.
>
> Por cierto, supongo que junit lo habrás quitado también.
>
> 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