User talk:Gerardo GR

From Apache OpenOffice Wiki
Jump to: navigation, search

Mi primer post en esta simulación de bitacora.

Primeros pasos

La primer actividad que estoy realizando como practicante del proyecto OpenOffice es conseguir OpenOffice y las herramientas necesarias para desarrollar extensiones (en la plataforma de desarrollo eclipse).

Instalando las herramientas

Ya he instalado exitosamente openoffice, de hecho cree un script para instalarlo en slackware y lo subi en una pagina que se dedica a distribuir esos scripts. Tambien he instalado el SDK de openoffice. Por ultimo termine de instalar el plug-in de eclipse para desarrollar aplicaciones con UNO para openoffice. Para instalar este plug-in segui esta guia, la recomiendo es util para llevar acabo esta tarea.
Despues de haber realizado la tarea de preparar el entorno de desarrollo (SDK,plug-in, etc), me preparo para correr algun ejemplo, el que he realizado con exito fue el del link mencionado anteriormente. El unico inconveniente que tuve, fue que al añadir una libreria externa, y correr la aplicación en openoffice a traves de un macro, me produjo la exepción de que no se encuentra la clase de la libreria añadida. Al finalizar el dia, me dedique a leer la guía de desarrolladores.

Conociendo la API de OpenOffice

El dia de hoy (01 de septiembre del 2011), lei la documentación acerca de la API de OpenOffice. Lo que aprendi es que utiliza un lenguaje llamado UNO que funciona como una interfaz entre los lenguajes de programación, entre ellos c++, basic y java. Por lo mismo que UNO funciona como interfaz, este tiene muchas interfaces que permiten el manejo de los objetos de openoffice.
Al mismo tiempo que iba leiendo la documentación, corri los programas de ejemplo y los analize. Uno de los ejemplos que corri, fue el siguiente, con este programa de ejemplo, tambien aprendi a como configurar el IDE eclipse para utilizar el SDK de openoffice y a configurar el build.xml (ant) para compilar diferentes programas, le hice unas pequeñas modificaciones para poder tener un script mas flexible. El cual quedo de la siguiente manera:

<?xml version="1.0" encoding="UTF-8"?>
<project basedir="." default="all" name="FirstLoadComponent">
 
	<!-- The following build script works with a standard installation of OpenOffice 3.0.1
	     and OpenOffice SDK 3.0.1 as described in section >Linux RPM-based Installation< 
	     of the document found at http://download.openoffice.org/common/instructions.html. -->
 
	<!-- This script is tested with the Eclipse IDE and stand-alone, without any IDE support. -->
 
	<!-- Paths based on the standard installation of OOo 3.0.1 and OOo SDK 3.0.1 on unix -->
	<property name="OFFICE_ROOT" value="/opt/openoffice.org" />
	<property name="OFFICE_HOME" value="${OFFICE_ROOT}/basis3.3" />
	<property name="OO_SDK_HOME" value="${OFFICE_HOME}/sdk" />
	<property name="OO_URE_HOME" value="${OFFICE_ROOT}/ure" />
 
	<target name="init">
		<property name="OUT_DIR" value="${basedir}/build/Example/" />
		<!-- For eclipse we need to set the output folder to this path -->
		<property name="BIN_DIR" value="${basedir}/bin/" />
		
		<!-- This variables help to have a more flexible build.xml.
			 APP_CLASS: name of the class.
			 OUT_JAR: name of the generated jar file.
			 PKG_NAME: name of the package tree we have in Eclipse -->
		<property name="APP_CLASS" value="FirstLoadComponent" />
		<property name="OUT_JAR" value="${APP_CLASS}.jar" />
		<property name="PKG_NAME" value="Example" />
	</target>
 
	<path id="office.class.path">
		<filelist dir="${OFFICE_HOME}/program/classes" files="unoil.jar" />
		<filelist dir="${OO_URE_HOME}/share/java" files="jurt.jar,ridl.jar,juh.jar" />
	</path>
 
	<fileset id="bootstrap.glue.code" dir="${OO_SDK_HOME}/classes">
		<patternset>
			<include name="com/sun/star/lib/loader/*.class" />
		</patternset>
	</fileset>
 
	<!-- Since the Eclipse IDE has an incremental compiler build in we do not need
	     to run the >compile< target in this case -->
	<target name="compile" depends="init" unless="eclipse.running">
		<mkdir dir="${BIN_DIR}" />
		<javac debug="true" deprecation="true" destdir="${BIN_DIR}" srcdir=".">
			<classpath refid="office.class.path" />
		</javac>
	</target>
 
	<target name="jar" depends="init,compile">
		<mkdir dir="${OUT_DIR}" />
		<jar basedir="${BIN_DIR}" compress="true" jarfile="${OUT_DIR}/${OUT_JAR}">
			<exclude name="**/*.java" />
			<exclude name="*.jar" />
			<fileset refid="bootstrap.glue.code" />
			<manifest>
				<attribute name="Main-Class" value="com.sun.star.lib.loader.Loader" />
				<section name="com/sun/star/lib/loader/Loader.class">
					<attribute name="Application-Class" value="${PKG_NAME}.${APP_CLASS}" />
				</section>
			</manifest>
		</jar>
	</target>
 
	<target name="all" description="Build everything." depends="init,compile,jar">
		<echo message="Application built. ${APP_CLASS}!" />
	</target>
 
	<target name="run" description="Try running it." depends="all">
		<java jar="${OUT_DIR}/${OUT_JAR}" failonerror="true" fork="true">
		</java>
	</target>
 
	<target name="cleanbin" description="Clean all binaries." unless="eclipse.running">
		<delete>
			<fileset dir="${BIN_DIR}">
				<include name="**/*.class" />
			</fileset>
		</delete>
	</target>
 
	<target name="cleanall" description="Clean all build products." depends="init,cleanbin">
		<delete file="${OUT_DIR}/${OUT_JAR}" />
	</target>
 
</project>

Archivos de propiedades de las extensiones

Le llamo archivos de propiedades de extensiones aquellos archivos xml que describen las propiedades de la extension, como son el nombre de la extension, la liga de donde se descargara una version actualizada, etc. Toda esta información le servira a la gestor de extensiones para poder realizar cierta funcionalidad, como el despligue de la licencia, o la actialización de la extension. Estos archivos son realativamente sencillos de entender y considero que para poder poner en practica este nuevo conocimiento lo mejor es empezar a leer bien codigos de ejemplo. El haber leido esa información me permitio entender mejor como se manejan las extensiones y que tipo de archivos son necesarios. Ahora me dispongo a analizar codigo de extensiones existentes para seguir con mi avance en las practicas.

Personal tools