Vaadin basic example

After the short introduction, server-side RIA framework, we are going to make a our first easy example with Vaadin. As we mentioned in the previous post Vaadin is perfectly integrated with Maven 2. There is a specific Maven 2 archetype for Vaadin which can be found in here Using Vaadin with Maven.

 

Vaadin , server-side RIA framework

Hoy vamos a hablar acerca Vaadin, un framework RIA que facilita el desarrollo de la parte de interfaz de usuario en aplicaciones web. Según la página oficial del proyecto, Vaadin es:

Vaadin is a server-side AJAX web application development framework that enables developers to build high-quality user interfaces with Java. It provides a library of ready-to-use user interface components and a clean framework for creating your own components. The focus is on ease-of-use, re-usability, extensibility, and meeting the requirements of large enterprise applications. Vaadin has been used in production since 2001 and it has proven to be suitable for building demanding business applications.

 

Empezar con Amazon Web Services. Crear credenciales de seguridad AWS y ejemplo básico

Vamos a seguir el manual Getting started que encontramos en la página oficial de Amazon.

Lo primero que tenemos que hacer para utilizar los servicios web que Amazon nos ofrece es subscribirnos como usuarios de Amazon. Para ello nos dirigimos a esta página. En concreto, picharemos en el enlace ‘Cree una cuenta AWS’ que encontramos en la zona superior de esta página.

 

Maven directory structure in a Java project

As we mentioned in the previous post Creating a new Java project with Maven , we are going to write about the basic directory structure that a project built with Maven has. As we said in An introduction to Maven, one of the main features of Maven is that follows the Convention over configuration pattern. This means that we have to place our classes, tests or resources in a predetermined directory so that Maven deals with them.

 

Estructura de carpetas de un proyecto Java con Maven

Como adelantabamos en el anterior post, Creación de un proyecto Java desde Maven , vamos a hablar de la estructura que tiene un proyecto base. Como comentabamos en Introducción a Maven, una de las principales características de Maven es que sigue el patrón de convención sobre configuración. Esto significa que debemos situar nuestras clases, tests o recursos en un lugar en concreto, para que luego Maven sea capaz de tratarlos correctamente.

 

Creating a new Java project with Maven

We have seen in the last post , An introduction to Maven, an overall perspective about Maven and its main features.

Maven allows us to create a project from either command line or with our prefered IDE. But before starting, it is a good idea remenbering what an archetype is, an archetype is an easy artefact that creates a project’s skeleton (prototype).With Maven we can create new projects through an archetype.

 

Creación de un proyecto Java desde Maven

Hemos visto en el anterior post Introducción a Maven un visión general sobre lo que es Maven y sus principales características.

Maven permite crear proyectos desde línea de comandos o bien desde nuestro IDE favorito. Pero antes recordar lo que era un arquetipo, un arquetipo es un artefacto sencillo que contiene el esqueleto (prototipo) de un tipo de proyecto que queremos construir. Maven nos va a facilitar la creación de nuevos proyectos utilizando el concepto de arquetipo.

 

Hibernate basic example with Apache Derby and Maven

We’re going to make a really easy test with Hibernate in our laptop. First, we’re going to configure an Apache Derby database. We are using Spring STS as our prefered IDE. Besides we will add Maven for our project’s dependencies .Configuring Hibernate in STS with Maven is an easy task. You only need to add your needings dependencies to our pom.xml file and start to coding.

 

Hibernate con Derby en Mac OSX / Linux

Vamos a hacer una prueba muy sencilla para trabajar con Hibernate en nuestro equipo. Para ello vamos a configurar una base de datos Apache Derby. Trabajaremos con el IDE de Spring de STS, además añadiremos Maven para la gestión de dependencias de nuestro proyecto.Configurar Hibernate en STS con Maven es sencillo. Lo único que hay que hacer es añadir las dependencias de Hibernate a nuestro pom.xml y empezar a programar.

 

Eclipse, plug-ins y demás …

Hola de nuevo,

últimamente he estado leyendo un poco sobre Eclipse y todo lo que rodea a este IDE. Seguramente muchos de vosotros lo utilizáis para desarrollar. Yo al menos lo utilizo y al leer un poco la documentación oficial sobre y alguno de los libros sobre Eclipse me he dado cuenta de lo mucho que desconozco una herramienta que utilizo todo los días y que tiene un montón de funcionalidades que no uso.

Además he logrado entender mejor como está montado Eclipse y lo fácil que es construir extensiones para él llamadas plug-ins. Previamente ya había desarrollado plug-ins ‘caseros’, pero por razones de trabajo estoy intentando hacer las cosas de una manera algo más ‘pofesional’ .

Comencemos con un poco de historia pues. El origen de Eclipse se llama VisualAge. En un pasado muy muy lejano se utilizaba VisualAge. Aquí abro un parentesis, donde estoy trabajando actualmente los desarrolladores siguen utilizando VisualAge para Java. Y no creaís que es una versión de las últimas. Es una versión de hace unos diez años más o menos. Los problemas que están surgiendo para migrar a un entorno de trabajo actual darían para unos cuántos post más. Pero eso es trabajo … . Cerrado el paréntesis, continuamos, VisualAge se desarrollo en Smalltalk por parte de IBM, que al igual que Java se trata de un lenguaje orientado a objetos. Pero a diferencia de Java, Smalltalk tenía poco apoyo por parte de la comunidad de desarrolladores. Por ello IBM, aprovechando que sus desarrolladores tenían experiencia con lenguajes orientados a objetos, decidió crear un nuevo IDE altamente extensible basado en Java. O lo que viene a ser Eclipse.

Eclipse, según la definición dada en el libro de Eclipse: Building Commercial Quality Plugins de Eric Clayberg and Dan Rubel:

no es un programa monolítico, sino un pequeño núcleo que contiene un cargador de plug-ins que incorpora cientos, pudiendo llegar a miles de plug-ins. Dicho pequeño núcleo es una implementación de la especificación OSGi R4 y proporciona un entorno en el qu ejecutar plug-ins. Cada plug-in contribuye al conjunto de forma estructurada, puede que dependa de servicios proporcionados por otro plug-in y, a su vez, puede que proporcione servicios de los que dependen otros plug-ins… El conjunto mínimo de plug-ins necesario para crear una aplicación cliente se denomina Eclipse Rich Client Platform (RCP). Dado qu la infrastructura de Eclipse se está empezando a utilizar para construir aplicaciones servidor además de las aplicaciones cliente, la infraestructura de Eclipse también se conoce como Eclipse Applicacition Framework (EAF)

En la siguiente imagen podemos ver la estructura interna de Eclipse:

Estructura básica de un plug-in Eclipse.
Los dos archivos que nunca van a faltar en un plug-in van a ser plugin.xml y MANIFEST.MF. En ellos vamos a declarar las dependencias y servicios de dicho plug-in. En la siguiente imagen, prestada también del libro, podemos ver con un poco más de detalle las entradas de cada uno de los ficheros:

El fichero de manifiesto MANIFEST.MF sirve para definir el nombre, versión y las dependencias (require-bundle) de nuestro fichero. Dos de las entradas más interesantes del fichero de manifiesto son:
- Bundle-Activator. que va a ser una clase que nos permite acceder a los recursos estáticos del plug-in, preferencias u otra información específica sobre el estado de nuestro plug-in.
- Bundle-ActivationPolicy. que nos permite indicar si necesitamos cargar nuestro plug-in al comienzo de Eclipse.

El fichero plugin.xml quizá resulte más interesante. Así pues podemos definir el punto de extensión, que para eso estamos desarrollando un plug-in, desde el que queremos empezar. En la imagen podemos ver que es org.eclipse.ui.views, es decir, nuestro plug-in va a ser utilizado como una vista de la interfaz de usuario de Eclipse.También podemos indicar la categoría de nuestro plug-in. Podemos asignar varios plug-ins a una misma categoría si por ejemplo queremos que éstos se muestren en una determinada vista de Eclipse. También podemos indicar la clase que implementará toda la lógica de nuestro código.

Hay dos tipos de plug-ins. Aquellos definidos como parte de la interfaz de usuario o que están basados en otros plug-in basados en UI y aquellos Core (centrales o de núcleo). A continuación enumero algunos tipos de plug-ins listados en el libro del que hemos estado hablando.
- Core: contienen servicios básicos como procesamiento de extensiones seguimiento de recursos, etc. ..
- SWT. biblioteca general de Widgets basados en UI integrados con el S.O. subyacente.
- JFace. biblioteca general de funcionalidades de la UI creada sobre el SWT.
- GEF(Graphical Editing Framework). Facilita el desarrollo de editores gráficos.
- Núcleo del entorno de trabajo. plug-ins que proporcionan un comportamiento no basado en UI, como proyectos, naturaleza de proyecto y preferencias.
- Trabajo en equipo. por ejemplo, CVS.
- Ayuda.
- Núcleo JDT y JDT UI. herramienta Java Development Tooling (JDT) de Eclipse.
- PDE( Plug-in development environment).
- Mylyn. plug-in que facilita el seguimiento de las tareas realizadas sobre un proyecto de desarrollo. Es uno de los plug-ins que no conocía y que más me han gustado ya que permite su interacción con bugzilla o jira por ejemplo

La verdad es que el tema de como está montado Eclipse y de las distintas extensiones (plug-ins) es bastante entretenido. Escribiré algún post más sobre el tema. De momento os invito a que leaís un poco al respecto.
Por cierto, Eclipse tiene una versión especial centrada en el desarrollo de plug-ins y Ajax llamada Eclipse for RCP and RAP Developers.

Un saludo.