Ejemplo de clase para gestionar informe birt

Lo pongo aquí a groso modo. Cuando tenga un ratito le doy mas formato y comento mas y mejor

 

ejecutar un informe desde línia de comanda

Dado que un .rptdesign es un elemento autónomo, que solo requiere para ejecutarlo y btener un informe, de la existencia de un runtime birt (este a su vez requiere un runtime java), podemos lanzar informes directamente desde linia de comanda. Por ejemplo, suponiendo que en c:\carpeta1\birt442 tenemos el runtime de versión 4.4.2, y queremos obtener un informe pdf a partir del diseño c:\carpeta1\prueba.rptdesign 
 

La manera en que birt analiza la comanda es muy fragil y caprichosa (por decirlo de alguna manera). Cosas a tener en cuenta son:
– no le gustan los guiones bajos en las rutas
– no le gusta que le cambien mucho el orden de los flags (por ejemplo, mejor que –file sea el ultimo)
– aunque funciona, muestra una traza de error grave quejandose de la inexistencia de una ruta (en el caso del ejemplo, de c:\carpeta1) 

Otras consideraciones:
Si prueba.rptdesign accede a bd, en la definición del datasource se habrá definido la cadena de conexión y el jar con los drivers.
Ambos se definen en duro con rutas absolutas. Aunque desde java se pueden cambiar dinámicamente, lanzando la comanda directamente no es posible, por tanto, ambas rutas han d’existir (en el caso de los drivers, aunque no existiese la ruta, si ponemos el jar en la misma carpeta que el .rptdesign, o bien en la carpeta c:\carpet1a\birt442\ReportEngine\lib\, será suficiente).
En el ejemplo hemos utilizado flags -p para un hipotético de parámetros. Naturalmente, si vuestro informe no los usa (creo que lo mas habitual es usarlos) o queréis que apliquen los valores por defecto, se pueden obviar.

Otro día vemos como ejecutar informes desde java.

gestión del ciclo de vida de los artefactos

El control del ciclo de vida de un proyecto nuestro, básicamente lo podemos controlar vía los plugins que configuremos en nuestro pom.xml.

Algunos de los plugins que podemos usar en nuestro pom, nos pueden parecer a primera vista ambiguos, o no saber muy  bien cuando utilizar uno u otro. Aquí iré dejando algunas notas acerca de ellos, cuando piense que puedan ser de utilidad o clarificadoras.

maven-jar-plugin, maven-war-plugin: permite generar jars o jars. por si mismo, no incuye en el paquete resultante ninguna de las dependencias que hayamos definido en el pom.xml, ni aunque estas esten definidas como compile (la generación del paquete no tiene en cuenta que una dependencia sea compile o provided; en principio, ninguna será incorporada a no ser que se especifique específicamente, por ejemplo, usando maven-assembly-plugin).

maven-assembly-plugin: permite incluir dependencias definidas en el pom.xml al paquete real que generaremos con nuestro proyecto. Si se abusa de el y cada ejecutable peca de usar jar’s o otros recursos que otros paquetes también incorporan en su interior, corremos el riesgo de abusar del tamaño de los proyectos.

Ejemplo de utilización del plugin maven-assembly-plugin con la finalidad de que la compliación de nuestro proyecto incorpore dentro del jar resultante las diferentes dependencias que hayamos definido en el pom.xml del proyecto, de manera que el artefacto resultante sea del tipo “with-dependencies” (“con todo incorporado dentro”):

 

maven-shade-plugin: Ejemplo de utilización, con la finalidad de que la compilación de nuestro proyecto genere un jar ejecutable (otra opción sería mediante el manifest.mf directamente, pero eso ya no sería un planteamiento maven)(obsérvese el uso que se hace del transformer, para indicar que maven se deberá comportar como si en el manifest.mf constara la clase ad.am.proyectoX.Main como clase de “arranque” del proyecto)   :

 

resolución de dependencias

Ejemplo de definición de una dependencia en el pom.xml de un proyecto:


Si no indicamos atributo scope (como en el caso anterior), maven interpreta por defecto que el scope es compile,
por lo que adjunta los artefactos a nuestro proyecto en tiempo de compilación.

Un ejemplo de cuando podemos querer utilizar dependencias compile, puede ser una aplicación que queremos poder ejecutar autónomamente, que simplemente copiando/pegando el jar resultante de la compilación en cualquier máquina con java pueda funcionar.

Si no queremos que nuestro artefacto crezca embebiendo un exceso de otros artefactos, maven prevée el scope provided, que compilará sin incluir la dependencia en nuestro artefacto resultante, ya que supuestamente, en el sitio en que despleguemos el resultado de nuestra compilación, nuestro artefacto ya encontrará ese otro artefacto.

Un ejemplo de cuando podemos querer utilizar dependencias provided, puede ser una aplicación war 
que haga uso de unos drivers (jar) que ya tenemos desplegados en el servidor web en que correrá la aplicación.

Los servidores vienen típicamente con una serie de modules ya incorporados (eg: artefactos apache), que pueden ser utilizables desde una un proyecto nuestro que los referencie como provided. También realizar un despliegue típico de un proyecto nuestro, como ejb o jar en el servidor de aplicaciones y posteriormente desplegar otro proyecto nuestro que referencie con scope provided al primero.

 

 

introducción a maven

Aquel que utiliza maven lo hace principalmente con dos objetivos. O bien gestionar las dependencias (etiquetas dependencies) que tiene nuestro proyecto hacia otros proyectos/artefactos de software, o bien gestionar el ciclo de vida de nuestro proyecto/artefacto (etiquetas plugin y otras). Para ambos usos, maven se basará en el pom.xml que espera que se halle en la raiz del proyecto. 

Un desarrollador puede trabajar con Maven tanto desde dentro como desde fuera de eclipse.
La mayoría de los ide’s de eclipse que podemos descargar desde la web oficial ya vienen con Maven. No obstante, si queremos trabajar desde fuera de eclipse con Maven
(lo que a veces esta bien para poder hacer scriptar con comandos Maven,
o para poder trabajar escapando del caprichoso comportamiento ocasional de eclipse),
puede ser interesante instalar también Maven de manera independiente en nuestro sistema.

Cuando instalamos Maven, bien sea como una pieza de software autónoma, como formando parte de Eclipse o algún otro ide, Maven, por defecto, conocerá el repositorio remoto estandar http://mvnrepository.com, como el repositorio local que se corresponde a la carpeta .m2 que la instalación habrá creado en alguna ruta del tipo C:\Users\Pepito\.m2

Si queremos obtener artefactos que no están disponibles en el repositorio estándar Maven, deberemos configurar nuestro acceso a url’s que publiquen otros catálogos/repositorios de artefactos (han de ser repositorios que estén accesibles bien a través de internet, bien a través de nuestra red interna). Dicha configuración la podemos hacer en el pom.xml, aunque resulta mas práctico hacerla en el settings.xml (ubicado en la raiz de la carpeta .m2. es decir, en la raíz de repositorio que utilizamos para desarrollar, compilar, o generar nuestros artefactos, en local), que se trata de un fichero de configuración de Maven que controla el comportamiento mas general de este, y es común a todos los proyectos con los que estemos trabajando en nuestro workspace.

Maven, conforme vamos trabajando con nuestros proyectos y definiendo dependencias en los pom.xml de los mismos, va manteniendo una sincronía del repositorio .m2 local con el/los repositorios remotos, de manera que en el .m2 podamos tener catalogados los artefactos que usamos habitualmente y así no tener dependencia absoluta de los repositorios remotos y de cortes en las comunicaciones para poder compilar y generar artefactos.

 

 

introducción a birt

La industria en general, no es que esté culpando yo a los de Eclipse (o al menos no específicamente), cada vez nos pone más difícil lo de hacer listados. Nos engañan diciendo que las herramientas de reporting ahora son Business Intelligence, y entonces hay que comprar licencias de base de datos, o llorar cuando Crystal Reports se va con Sap y nos deja a todos huerfanitos.

Bueno. Algo habrá que utilizar. Sinceramente, me gusta antes Pentaho o otros productos antes que Birt, pero no vamos a discriminarlo. En próximos dìas le dedicaré algún articulillo para que esté contento. Mientras tanto…

Birt es un proyecto opensource que permite crear informes para clientes pesados y aplicaciones web java.
Tanto el componente diseñador como el runtime, requieren java, por lo que aconsejamos jdk o jre 1.7, o posterior.
.
El diseñador:
.

Para realizar los diseños de informes utilizaremos el componente diseñador. El diseñador puede instalarse como plugin del eclipse que estemos utilizando, o bien instalar un eclipse con el plugin preinstalado.

Nuestro consejo es optar por la opcion del ide con el plugin de diseño birt preinstalado y usarlo solo para eso.

Una vez superada la etapa de diseño, no hay problema por mover el .rptdesign al lugar desde donde queramos que nuestros proyectos lo tomen.
Por ejemplo, podemos descargar el ide eclipse all in one en http://download.eclipse.org/birt/downloads / all-in-one / download now

Lo que nos descarga un eclipse-reporting-neon-R-win32-x86_64.zip desenzipable y operativo directamente para comenzar a diseñar informes.

Para ejecutar informes desde el ide, no nos hace falta descargar nada mas, ya que el paquete aquí comentado incluye un runtime birt,
y el propio eclipse lo maneja. Eso si, si debemos conectar los .rptdesign con los que estamos trabajando a bd’s, necesitaremos indicar las cadenas de conexión correspondientes al momento de definir el datasource, y claro, si para establecer dicha conexión hace falta algun jar con drivers, en la definición del datasource también debemos definirle la ruta de dicho jar.
Lamentablemente, solo admite rutas absolutas, por lo que muchas veces la ruta que utilizemos en fase diseño no se corresponderá con la que queramos emplear en producción. Afortunadamente, desde java podremos modificar dinámicamente algunas de este tipo de carácterísticas del .rptdesign.
.
El runtime:
.

En cuanto a la ejecución de los informes, deberemos utilizar un runtime.

El ide all-in-one, ya trae un runtime incorporado, pero solo nos vale si lanzamos un informe desde el propio ide. Por ejemplo, podemos descargarlo de http://download.eclipse.org/birt/downloads/#runtime
Como mencionábamos mas arriba, para ejectuar los informes (.rptdesign) desde el propio ide del diseñador, no nos hace falta otro runtime
que el que ya viene con el ide. Para proyectos puestos en producción, si que lo necesitamos.

consumo de servicio web de coinmarketcap

ejemplo de consumo de un servicio web rest y de utilización básica de Google Gson.

A algunos de nosotros, con conocimientos de programación, nos puede servir de ayuda, hacernos programas muy sencillitos que nos controlen cosas de CoinMarketCap, de Binance, o otros sitios del estilo.

Por ejemplo, imaginemos que queréis utilizar la api que publica CoinMarketCap para obtener una lista de las criptomonedas que muestran en su página web para posteriormente trabajar con ellas con nuestros programas java, para saber cotizaciones, tickers, movimientos de capital, … Necesitaremos una url  (en este caso, api.coinmarketcap.com/v1/ticker/?limit=…) y algo de código…

 

y la clase ActivoCMC podría tener, por ejemplo, esta forma…