Mostrando entradas con la etiqueta eclipse. Mostrar todas las entradas
Mostrando entradas con la etiqueta eclipse. Mostrar todas las entradas

martes, 23 de marzo de 2021

Como ejecutar pruebas con JUnit5 y Mockito en Eclipse

Hoy vamos a ver algo muy sencillo, y es simplemente como hacer funcionar JUnit y Mockito desde Eclipse. No es un gran post que nos aporte o clarifique el funcionamiento concreto de una tecnología. Pero si es un post de ayuda que puede sernos util tenerlo a mano para configurar rapidamente nuestro proyecto, sobre todo si no tenemos buena memoría. 

Eclipse es uno de las herramientas de desarrollo más famosas y mi preferida, al menos cuando en cuanto a Java se refiere. Facilita mucho el trabajo y en el caso de las pruebas, te permite ejecutarlas facilmente a través del menú contextual. Pudiendo ejecutar un único tests o todos los tests de una determinada clase o proyecto. 

El asunto, es que con JUnit 5, no es que sea dificl hacerlo funcionar pero si que requiere de un mínimo de configuración. 

Antes de empezar vamos a ver como siempre un poco de teoría. JUnit 5 es la suma de tres proyectos diferentes:

  • JUnit Platform: Es la base del Framework de testing. Y contiene la API de testing que nos permite ejecutar lso tests. 
  • JUnit Jupiter: Es la librería que contiene el nuevo modelo de programación de JUnit 5 y su modelo de extensión. Incluye anotaciones como @Tests, imprecindibles. 
  • JUnit Vintage: Es el proyecto que nos permite ejecutar versiones antiguas de JUnit, concretamente las versiones 3 y 4. Por tanto, este proyecto no lo necesitaremos. 
Lo primero que debemos configurar son las dependencias: 

<!-- junit.jupiter.version = 5.7.1 -->
<!-- junit.platform.version = 1.7.1 -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>${junit.jupiter.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-runner</artifactId>
<version>${junit.platform.version}</version>
<scope>test</scope>
</dependency>

Ya solo nos queda preparar nuestro test para que podamos ejecutarlo. Las pruebas las podremos ejecutar desde Eclipse o con comandos Maven. Eso sí, para ejecutarlas desde eclipse es necesario utilizar el Eclipse Photon o alguno posterior. 

Aparte del la anotación imprescindible de @Test sobre cada uno de los tests que desarrollemos. Esta última anotación es la que permitirá que los métodos de la clase sean tenidos en cuenta como tests por Eclipse.

public class BookDaoTest {
@Test
void getBook(final TestInfo testInfo) {
BookDao dao = new BookDao();
Book book = dao.getById(0L);
assertThat(book.getId(), equalTo(0L));
}
}

Pero necesitaremos una actualización más de nuestro proyecto si queremos que dichas pruebas sean tenidas en cuenta por Maven. Y es usar una versión del plugin maven-surefire-plugin superior a 2.22.0

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.2</version>
</plugin>

Como hemos dicho podemos ejecutar el código con el típico comando de maven:

mvn clean test

O directamente sobre eclipse a través del menú contextual, si queremos ejecutar únicamente una clase o método concreto:


Ahora llega el turno de Mockito, algo que tampoco es complicado. Mockito es una librería genial que nos ayuda a 'mockear' objetos concretos para por ejemplo, poder devolver una respuesta concreta por nuestro objeto o simular respuesta de objetos que no conseguirias de otra forma. Podemos decir que también es una librería fundamental si queremos una gran cobertura de nuestras pruebas. 

Lo primero que tendremos que hacer será incluir la dependencia de Mockito. Este framework tiene una dependencia específica para la ejecución de pruebas de JUnit 5. 

<!-- mockito.version = 3.8.0 -->
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>${mockito.version}</version>
    <scope>test</scope>
</dependency>

El siguiente paso será añadir la extensión @ExtendWith a nuestra clase de Test, indicando que vamos a usar la extensión MockitoExtension que hace uso del modelo de extensión de JUnit 5. 

@ExtendWith(MockitoExtension.class)
public class BookDaoTest {
	@Mock
	BookDao dao;
	@Test
	void getBook(final TestInfo testInfo) {
		Book bookMocked = new Book(0L, "Orson S. Card", "Ender's Game");
		when(dao.getById(0L)).thenReturn(bookMocked);
		Book book = dao.getById(0L);
		assertThat(book.getName(), equalTo("Ender's Game"));
	}
}

Como veis con 3 dependencias y 1 anotación ya podemos ejecutar sin problemas dos de los frameworks de testing más importantes en nuestro IDE preferido. 

martes, 14 de mayo de 2019

Lombok: Como reducir código tan necesario como tedioso

Hoy vamos a ver una librería pequeña pero super util, que nos va a evitar escribir código tedioso como son los getters y setters. Lombok nos permite hacer esto y más a través de anotaciones.

Antes de empezar a ver ejemplos, lo primero que tenemos que hacer es habilitar que nuestro IDE comprenda las anotaciones de Lombok y que en tiempo de compilación puedan ser usadas. Si usamos eclipse, debemos bajar el jar de la librería, por ejemplo de maven central, y ejecutar dicho jar con el comando java -jar. Esto nos abrirá un menú de instalación que nos permitirá instarlo en nuestro IDE.

Lo siguiente será añadir la librería como dependencia de nuestro proyecto. Una vez configurado podemos ver ejemplos de anotaciones y su funcionamiento. Una prueba del mismo, será al incluir nuestras anotaciones ver la vista outline, donde se habrán generado los metodos asociados a las anotaciones. 
  • @NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor. Nos permiten crear constructuros de clase.
@NoArgsConstructor
@AllArgsConstructor
public class Saludo
  • @EqualsAndHashCode, @ToString. Anotaciones de clase que permiten generar métodos comunes de clase.
@ToString
@EqualsAndHashCode
@Entity
public class Book extends GenericEntity<Integer>{
  • @Getter, @Setter. Nos permiten olvidarnos de los famosos getter/setters.
private @Getter @Setter String saludo;
  • @Data que auna las anteriores anotaciones: @ToString, @EqualsAndHashCode, @Getter, @Setter y @RequiredArgsConstructor
  • @Value. Al reves que @Data crea todos los métodos igual que este, exceptuando los setters, ya que los atributos serán declarados como privados y finales. 
  • @CommonsLog, @Log, @Log4j, @Log4j2, @Slf4j, @XSlf4j. Nos permiten generar el atributo log del tipo que deseemos para realizar las trazas de nuestro proyecto.
@Log4j
@RestController
public class SaludoRestController {
    @GetMapping("/saludo")
    public Saludo Saludo(@RequestParam(value = "nombre", defaultValue = "World") final String nombre) {
        log.info("Saludo - init");
        return new Saludo("Hola", nombre);
    }
}
  • @NonNull, lanzará un NullPointerException si el parámetro asociado es nulo.
@GetMapping("/{id}")
public Book findById(@NonNull @PathVariable("id") final Integer id) {
    return repository.findOne(id);
}
  • @Cleanup. Genera un bloque finally y cierra el recurso asociado a la anotación. Aunque si es closeable el recurso tampoco tiene mucho sentido en mi opinión. 
Podeis ver el código del ejemplo aquí.


domingo, 31 de marzo de 2019

EclipseTips: Como sacar provecho a tu IDE

Hoy vamos a ver varios trucos de eclipse, para mi gusto el mejor IDE para java. Esta no es idea original mía (igual no hay ninguna en todo el blog :-P) sino que la he sacado de Twitter. El contenido se basa en el hashtag #EclipseTips, que es utilizado mayormente por la cuenta @EclipseJavaIDE. La idea es hacer una pequeña recompilación de los más interesantes y/o desconocidos. En cada descripción irá un enlace al tweet que contiene al truco. 
Selecciona un conjunto de String concatenados, botón secundario y pulsar 'use StringBuilder for concatenation'.
A la hora de autocomplementar puedes poner las letras mayúsculas del método para llegar antes a el. Similar a gradle.


Poniendote sobre un equals y pulsando 'Ctrl+1' puedes invertir su orden. Util para evitar NullPointetException sino usas Apache Commons-Lang


Si te pones sobre el atributo y pulsas 'Ctrl+1' te puedes crear su getter and setter específico. Pero si pulsas sobre la clase con botóns secundario, dentro de la sección 'source' esta la opción 'Generate Getters and Setters' que te permitirá crear todos los que aún no se han creado de una vez.

Creando solo el valor de la variable o atributo (Ej: 1;). La seleccionamos y pulsamos "Ctrl+2+L" crearemos una variable local (para el ejemplo un entero), pero si pulsamos "Ctrl+2+F" crearemos un atributo de clase. 
Si seleccionamos una variable y pulsamos 'Alt+Shift+R' se abrirá un menú para renombrar dicha variable. pero si lo pulsamos dos veces se abrirá un menú más amplio que nos permitirá indicar que se cambien los getters y los setters también.
Seleccionando una linea completa de código y pulsando 'Alt+up' o 'Alt+Down' puedes mover dicha linea arriba o abajo. 

Si por el contrario quieres copiarla arriba o abajo usa 'Ctrl+Alt+Up' o 'Ctrl+Alt+Down'.

domingo, 20 de mayo de 2018

Problemas con Hibernate Tool y Eclipse : Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]

Ya me ha pasado un par de veces y para eso cree este blog. Así que vamos a apuntar aquí como resolver este problema.

El problema viene porque estoy intentando crear una 'Hibernate Configuration' dentro de Hibernate proporcionada por Hibernate Tools. En principio tengo todo bien configurado pero a la hora de hacer el amago de conexión me indica el siguiente error:

org.hibernate.console.HibernateConsoleRuntimeException: Could not load AnnotationConfiguration

org.hibernate.console.HibernateConsoleRuntimeException: Could not load AnnotationConfiguration
 at org.hibernate.console.ConfigurationFactory.buildConfiguration(ConfigurationFactory.java:159)
...
Caused by: org.hibernate.service.spi.ServiceException: Unable to create requested service [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]
 at org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:271)
 ... 12 more
Caused by: org.hibernate.exception.JDBCConnectionException: Error calling Driver#connect
 at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:115)
 ... 32 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

Como vemos el error no es muy aclaratorio y basicamente te dice al final que no es capaz de conectarse con la BBDD.

El problema radica en como se ha indicado anteriormente, para crear esa 'Hibernate Configuration', la 'Database Connection'.  Al crear dicha conexión debes indicar los datos de configuración pero también que driver vas a utilizar. Y aquí es donde radica el problema, además tienes que aportar el jar de dicho driver.

PD: Una forma de obtenerlo rápido es ir a cualquier repositorio de maven, buscar la versión que queramos y descargarlo desde ahí.

martes, 7 de noviembre de 2017

Como importar clases estáticas automaticamente en eclipse


Ultimamente estamos hablando mucho de software relacionado con el testing. Estas librerias tienen además una particularidad compartida. Y es que suelen hacer uso de clases y métodos estaticos. Con eclipse podemos importar las clases de forma automatica, tanto las normales como las que no. Y aquí explicaremos como.

Por si alguien no lo sabe, primero indicaremos como realizar la importacion automática de las clases que no son estáticas. Para ello debemos ir a 'Eclipse>Preferences>Java>Editor>Save Actions' y marcar las opciones:
  • Perform the selected actions on save
  • Organize imports
Esta sección sirve para mucho más. Pero solo con esto cada vez que guardemos nuestro fichero .java, eclipse se encargará de ordenar e importar todas las clases utilizadas.

Con la opción anterior no se importarán las clases o métodos que se hagan de ellas una invocación estáticas. Para ello necesitaremos una modificación de las preferencias más. Debemos acceder a 'Eclipse>Preferences>Java>Editor>Content Assist'. En esta sección debemos ir añadiendo 'New Types', es decir indicar la paquetería de las clases estáticas que queremos importar de forma automática (sin el asterisco, este lo pone tras la creacion automáticamente).



Las importaciones más comunes  para poner aqui serían las de JUnit o Hamcrest. Tal como se ven en el ejemplo.


jueves, 17 de diciembre de 2015

Tareas Ant y JDK. Como indicar el JAVA HOME

Para el control de proyectos no hay nada mejor que el Maven. Pero todo hay que decirlo, si necesitas generar WARs para diferentes versiones, lo mejor es usar una tarea Ant que nos permita crearlos todos a la vez.
Un problema que me he encontrado realizando tareas parecidas a través del Eclipse, es que la tarea Ant suele coger el JDK de la variable de entorno JAVA HOME del sistema y no del indicado en el propio Eclipse. Para poder indicar la JDK que tu quieras, aquí un ejemplo:
En primer lugar crear las propiedades donde indicas en que luegar se encuentra el JAVA HOME y el MAVEN HOME. Luego en la instrucción que permite generar el WAR a través del MAVEN.











martes, 29 de septiembre de 2015

Mavenizar una aplicación web

Buenas, este es un post muy sencillo que llevo un tiempo queriendo hacer. Hay veces, aunque cada vez menos, que nos podemos encontrar con una aplicación web que no tenga maven. Para gestionar correctamente una aplicación lo mejor (al menos lo que yo uso) es que tenga Maven. A continuación indicamos los pasos a seguir.

Como bien sabéis una aplicación web tradicional tiene el siguiente formato:
  • Una carpeta de código fuente denominada /src.
  • Una carpeta que contiene la información de la aplicación a desplegar denominada /WebContent.
  • Una carpeta que contiene la información no accesible para el usuario denominada WEB-INF localizada /WebContent/WEB-INF.
  • Un documento denominado web.xml que es esencial para la aplicación y que contiene su configuración más básica. Y que estaría ubicado dentro de la carpeta WEB-INF.
 Las aplicaciones Maven tienen una configuración por defecto distintas a la de una aplicación web normal. Por lo que habrá que hacer ciertos ajustes para su correcta configuración. Debemos tener en cuenta que por defecto una aplicación web con maven tiene la siguiente configuración:

  • Cuatro carpetas de código fuentes: /src/main/java (que contiene el código de la aplicación), /src/main/resources (que contiene los archivos de configuración de la aplicación), /src/test/java y /src/test/resources (que son iguales que los java pero solo para los test y que no se incluirán en los .jar). 
  • Una carpeta que contiene la información a desplegar /src/main/webapp. Lo que sería el equivalente al 'WebContent'. 
  • La carpeta WEB-INF con el fichero web.xml dentro de la carpeta 'webapp'. 
  • Un fichero denominado pom.xml que se encuentra en la raíz del proyecto y que contendrá la configuración de Maven. 
 Tras esta breve explicación, los pasos a seguir serían para hacer una aplicación Maven son:

1. Añadirle el fichero pom.xml. El fichero debe de tener una configuración básica. Y esta es:
  • El groupId, artifactId y versión propios de la aplicación. Serán los valores que nos permitirán identificar esta aplicación de otras. Ejemplo:
 es.home.test
 appTestMaven
 1.0.0
  • Indicar si la aplicación se desplegará como un WAR o un JAR (en nuestro caso un war) y el nombre de la aplicación al desplegar:
 war
 appTestMaven
  • Indicar las librerías de las que depende. Este es el apartado más complicado, puesto que no sepamos siempre cuales son sus dependencias exactas. Para indicarlas debemos crear el apartado 'dependencies' e ir incluyendo las dependencias de una en una, ejemplo:
   org.springframework
   spring-core
   3.2.8.RELEASE

    2. Indicar que el proyecto pasa a ser un proyecto Maven. La forma de hacerlo en Eclipse es pulsando el botón derecho sobre el proyecto y en el menú secundario seleccionar las opción: Configure > Convert to Maven Project. 

    3. Al hacer el paso anterior se habrá generado ya la configuración de proyecto Maven, ya solo nos quedará ajustarla. Para ello hacemos lo siguiente:
    • Creamos las carpetas /src/main/java, /src/main/resources, /src/main/webapp, /src/test/java y /src/test/resources. - Movemos los recursos de la carpeta /src a /src/main/java 
    • Movemos los recursos de la carpeta /WebContent a /src/main/webapp 
    • Eliminamos la carpeta build (ya no la necesitaremos). 
    4. Actualizamos el proyecto, para ello pulsamos el botón derecho sobre el proyecto y seleccionamos la opción: Maven > Update project y en la ventana secundaría que aparece pulsamos 'Ok'. Esto nos sirve porque es posible que Eclipse no haya configurado correctamente el proyecto y necesite que se le indique de forma manual.

    Con esto en principio ya tendremos mavenizada la aplicación. Es más fácil de hacer que de decir, eso seguro. 

    sábado, 8 de agosto de 2015

    Importar proyecto en eclipse sin .project

    Esto es una tontería pero puede que todo el mundo no lo sepa, sobre todo aquellos que comienzan en el mundo de la programación.

    La forma para poder importar un proyecto (que no sea maven y tenga su fichero pom.xml), es dándole a crear nuevo proyecto (del tipo que queramos).

    Ahora viene la clave, lo único que deberemos hacer es desmarcar la casilla 'Use default location'  que se encuentra debajo del campo que nos permite darle nombre al proyecto. De esta forma se habilita un selector de carpetas en la parte derecha, en el cual nos permitirá indicar la carpeta raíz de nuestro proyecto. Ya solo queda terminar de crear el proyecto y veremos como esta importado.

    jueves, 27 de marzo de 2014

    Tomcat - error : No existe o no es un directorio legible

    El otro día estaba trabajando con el eclipse y el tomcat. En el tomcat tenia varias aplicaciones pero se las quite todas y me puse a trabajar solo con una dentro del tomcat. El asunto es que al arrancar el tomcat, aunque lo hacía sin problemas me decía que no podía cargar una determinada aplicación llamémosla 'appB' porque appB no existe o no es un directorio legible.

    El asunto es sencillo, dependiendo de como este montada la aplicación esta puede dejar un fichero descriptor de su contexto dentro del tomcat. Y aunque borres la aplicación del tomcat a través del eclipse, ese fichero descriptor de la misma continuara dentro del tomcat.

    Lo que hay que hacer es sencillo, dirigirse a la carpeta {tomcat_dir}\conf\Catalina\localhost y borrar el documento xml con el nombre de la aplicación que nos da fallo, en este caso será 'appB.xml'.

    miércoles, 29 de mayo de 2013

    ¿Porqué quartz lanza dos veces la tarea?

    Buenas.

    Tengo una aplicación realizada con Spring y dentro de ella tengo una tarea interna. Para realizar la tarea interna, he utilizado Quartz que es un planificador muy fácil de usar y sencillo de integrar en Spring (algún día puede que ponga algo de como hacerlo).

    El asunto es que aunque la configuración parece estar correcta y en entornos posteriores no parece haber ningún problema. Cuando intento hacer test sobre la tarea y debugar, me doy cuenta que dicha tarea es invocada dos veces.

    Estuve googleando para ver cual podía ser la razón del error, pensando que el problema podía estar en la configuración de Quartz. Pero no es así, el fallo esta en el tomcat.

    Yo despliego la aplicación en un Tomcat que manejo a través del eclipse. Como es normal, para facilitar el trabajo de desarrollo, Tomcat esta configurado para que se despliegue automáticamente cada vez que se realiza un cambio en el proyecto. Esto puede llevar a que se cree dos veces el web.xml. Y por tanto hace que se cargue el contexto de Spring dos veces y a la misma vez, se carga la configuración de quartz 2 veces. Y de ahí que se invoque dos veces la tarea.

    ¿Solución? Evitar que Tomcat haga el despliegue automático para evitar la creación doble del fichero descriptor de la applicación y quitar del server.xml la descripción del contexto de la aplicación. Tal y como comenta en su propia documentación

    When using automatic deployment, the docBase defined by an XML Context file should be outside of the appBase directory. If this is not the case difficulties may be experienced deploying the web application or the application may be deployed twice.

    Finally, note that if you are defining contexts explicitly, you should probably turn off automatic application deployment. Otherwise, your context will be deployed twice each, and that may cause problems for your app.

    También puede ser que se tenga dos veces la carga del contexto de spring en el fichero web.xml.

    jueves, 9 de mayo de 2013

    Problema al asociar librerias a un proyecto android en eclipse


    Me he encontrado con un error de estos raros que tardas días en resolverlo y es el siguiente. 

    He estado realizando un breve ejemplo con android y en este usaba a otro proyecto android como librería dependiente. El asunto es que por más que seguía los diferentes tutoriales y parecían estar bien, mi ejemplo no funcionaba. 

    A mitad del proceso de resolución me di cuenta que era debido a las propiedades de mi proyecto, concretamente al indicar que había otro proyecto android que era usado como librería. Aunque en un primer momento eclipse lo configuraba correctamente, si se accedía una segunda vez a las propiedades, la librería ya no se encontraba correctamente configurada. Indicaba como si no fuese posible encontrar la librería dependiente.


    Un poco desesperado me baje un ejemplo para ver si mi código tenía algún fallo. Y aunque el ejemplo descargado funcionaba correctamente, el código en ambos proyectos era el mismo. Al entrar en las propiedades del proyecto de ejemplo compruebo que la librería se encuentra correctamente configurada. Con esto certifico que el error proviene de donde sospechaba pero no entiendo porque en el ejemplo funciona y no en mi proyecto. 


    Tras seguir indagando lo único que veo es que en el código de ejemplo la librería esta indicada mediante ruta relativa y en mi proyecto esta indicado mediante ruta absoluta. Y ahí esta el fallo, las librerías de android deben ser indicadas mediante rutas relativas. Y una vez que se la razón, encuentro en la documentación de android el párrafo indicando dicha eventualidad. Por tanto hay que estar atento a esto a la hora de indicar dependencias entre proyectos android.
    • Library project storage location
    There are no specific requirements on where you should store a library project, relative to a dependent application project, as long as the application project can reference the library project by a relative link. What is important is that the main project can reference the library project through a relative link.

    viernes, 1 de marzo de 2013

    Error: no persistence provider for entitymanager named

    Haciendo una pequeña aplicación con JPA me he encontrado con este problema. Y hay dos causas por las que puede fallar:
    La primera de ellas es la más evidente, que no se haya incluido en el fichero persitence.xml el 'provider'. Este provider no es más que el software encargado de manejar la conexión. El caso más usual es que sea Hibernate.
     org.hibernate.ejb.HibernatePersistence
    

    Pero si usamos el eclipse aún así puede que nos de un error. La solución tampoco es muy complica y reside en que eclipse quiere que incluyamos el fichero persistence.xml en una ruta concreta. Esta ruta es en uno de los source package (usualmente el de resources) y dentro de la carpeta META-INF.

    jueves, 28 de febrero de 2013

    Importar un proyecto de Github

    En anteriores post hemos hablado sobre git y eclipse, como instalar el plugin o como subir el proyecto a Github. En este indicaremos como importar un proyecto existente desde Github al eclipse.

    Vamos a la barra de herramientas del eclipse y seleccionamos la opción File > Import. Una vez dentro escogemos la opción 'Projects from Git'. Tras pulsar 'Next' nos da la opción de importar un proyecto local o remoto, escogemos la opción 'URI'.

    En la siguiente ventana que nos aparece indicamos la url HTTP que nos provee Github con nuestro repositorio e indicamos nuestro usuario y contraseña.




    Tras pulsar 'Next' seleccionamos la rama principal para descargar. Tras pulsar de nuevo 'Next' procedemos a crear el repositorio local que usará el proyecto.

    En el siguiente paso marcamos la opción de 'Import existings projects' y ya solo nos quedará pulsar 'Next' con las opciones por defecto en las próximas ventanas.



     Esta opción la veo mejor que subir directamente el proyecto desde nuestro local porque el enlace con Github se mantiene almacenado y no es necesario indicarlo cada vez que se haga un 'Push'. Por tanto cada vez que realicemos un cambio en nuestro código podemos hacer un commit y un push enlazado.

    Asociar un proyecto a GitHub


    En un post anterior indicamos como añadir el plugin de EGit a Eclipse. En este indicaremos como subir nuestro proyecto a Github.

    Github es una plataforma de desarrollo colaborativo de Git el software de control de versiones. Lo primero que debemos hacer es crearnos una cuenta en Github, en la página oficial https://github.com/.

    Una vez creada la cuenta procedemos a crear un repositorio. Este será el lugar en la nube donde almacenaremos nuestro proyecto. Para ello simplemente debemos pulsar el botón de 'Create a new Repo' en la parte superior derecha de la Web y seguir unos sencillos pasos.

    Posteriormente necesitamos crear una clave y asociarla a nuestro repositorio de GitHub. Una forma sencilla de crearla es a través el eclipse. Para ello vamos en las preferencias del eclipse a General > Network Connections > SSH2 y en la pestaña de Key Management pulsamos sobre el botón 'Generate RSA Key'.

    Esta clave es la que debemos añadir a Github de la siguiente forma. Dentro de GitHub vamos a Accounts setttings > SSH Keys y pulsamos sobre el botón 'Add SSH Key'.







    Los siguientes pasos van destinado a poder subir nuestro proyecto al repositorio que hemos creado, el cual se encuentra vacio por ahora. Para ello vamos al eclipse y pulsamos el botón secundario sobre nuestro proyecto y seleccionamos la opción Team > Share Projects...

    En un primer momento debemos crear nuestro repositorio local de git y posteriormente subirlo a Github. Para ello procedemos a crear el repositorio local. Y una vez creado pulsamos sobre el proyecto con el botón secundario y seleccionamos la opción Team > Commit. Con esto ya tendremos activo el control de versiones de manera local y podemos trabajar con nuestro proyecto. Ahora vamos a ver como subirlo a la nube.

    Pulsamos con el botón secundario sobre el proyecto y seleccionamos la opción Team > Remote > Push. En la URI debemos poner la dirección HTTP que nos facilita Github. Podemos acceder a esta dirección desde la Web a través de Account Settings > Repositories y seleccionando el repositorio creado.





    En el siguiente paso elegimos la versión a subir de nuestro proyecto. Como solo tenemos una es sencillo, seleccionamos la opción master tanto en 'Source ref' como en 'Destination Ref' y pulsamos sobre el botón 'Add Spec' y luego en 'Next'. Nos saldrá una ventana donde indicar nuestro usuario y empezará a subir el proyecto.


     Y esto es todo para poder trabajar con Git y Eclipse y mantener el proyecto de forma remota.

    miércoles, 27 de febrero de 2013

    Instalar plugin de Git en Eclipse


    En este post vamos a explicar como instalar el plugin de Git en eclipse

    Git es un software de control de versiones de código libre. Vamos lo mismo que es el más antiguo y conocido SVN. Git lo podemos encontrar en esta página.

    Podemos crearnos nuestro propio repositorio local o tener un remoto (GitHub). Pero eso lo veremos más adelante, en este post simplemente veremos como añadir EGit.

    Partimos de una base en la cual ya tenemos el eclipse instalado. En mi caso la versión Juno.

    Dentro del eclipse vamos a Help > Eclipse marketplace. Una vez abierta la venta seleccionamos el marketplace correspondiente a nuestra versión de eclipse y buscamos egit. Nos saldrá una opción a elegir que  seleccionamos para instalar. Nos pedirá que marquemos los software a instalar (los marcamos todos) y también que aceptemos la política de uso.

    Con estos sencillos pasos ya tenemos instalado EGit, en posteriores posts indicaremos como usar Git con nuestro proyecto.

    Esto mismo que he explicado para instalar EGit sirve igual para todos los plugins de Eclipse.

    lunes, 23 de abril de 2012

    Crear adaptador de servidor weblogic en eclipse

    Tras tener el weblogic preparado, lo siguiente es crear un nuevo adaptador en el eclipse que nos permita el manejo del servidor a través de el.

    La versión utilizada es eclipse indigo, y por defecto no incluye ningún adaptador para servidores weblogic, para que se muestren estos adaptadores debemos instalarlos antes. Para ello, en la pantalla de definición de un nuevo servidor hay un enlace en la esquina superior derecha, el cual abrirá una nueva ventana donde seleccionaremos el servidor que nos interesa, weblogic en nuestro caso.

    Se ha usado la versión indigo de eclipse, porque es posible que en versiones anteriores estos adaptadores no se ecuentren disponibles ni para descargarse o no se encuentre la versión.

    Una vez seleccionado el servidor e instalado pasamos a crear el adaptador para usar nuestro servidor.

    Sobre la ventana de server, pulsamos con el botón derecho y seleccionamos la opcion new>server. Dentro de la lista de opciones que incluye seleccionamos oracle weblogic 12c. Pulsamos next y vamos a la siguiente pantalla.

    En la pantalla de creación del servidor debemos indicar donde se encuentra el servidor y el jdk. Aunque lo hagamos correctamente es posible que eclipse no nos permita seguir en la creación del adaptador, y esto es debido a un bug. Para conseguir instalar el adaptador seguimos los siguientes pasos.

    En weblogic home seleccionamos donde instalamos en el servidor y posteriormente escribimos a mano "/wlserver". Seleccionamos la carpeta donde se encuentra la jdk y ya podemos seguir con el proceso.

    En la siguiente pantalla seleccionamos donde hemos puesto el dominio y ya esta instalado el servidor

    Problemas en la instalación de weblogc 12c

    Estaba intentando instalar un servidor wweblogic 12c. Y si se siguen los pasos de instalación que vienen en el archivo README.txt es bastante sencillo. Pero me ha fallado en los dos ultimos pasos. Los pasos son los siguientes:

    1. Extraer el contenido del zip en un directorio y referirse a el como MW_HOME (ej: /home/myhome/mywls).

    2. Establecer las variables de entorno JAVA_HOME y MW_HOME
        $ export JAVA_HOME=/home/myhome/myjavahome
        $ export MW_HOME=/home/myhome/mywls
    
    3. Ejecutar el script de configuración. Solo debe ser ejecutado una vez a menos que se cambie la localización del servidor.
        $ . ./configure.sh
    
    4. Ejecuta el archivo para establecer las variables de entorno de WLS.
        $ . $MW_HOME/wlserver/server/bin/setWLSEnv.sh
    
    5. Crea un nuevo dominio WLS y arranca la máquina. El dominio es recomendable tenerlo fuera de MW_HOME.
        $ mkdir /home/myhome/mydomain
        $ cd /home/myhome/mydomain
        $ $JAVA_HOME/bin/java $JAVA_OPTIONS -Xmx1024m -XX:MaxPermSize=128m weblogic.Server
    
    Para empezar cuando intentaba ejecutar weblogci.Server, me indicaba que las no encontraba la clase definida:
    java.lang.NoClassDefFoundError: weblogic/Server
    Caused by: java.lang.ClassNotFoundException: weblogic.Server
    at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
    
    A pesar de que estaba realizando el paso 4, las variables de entorno no se guardaban correctamente. Como al ejecutar el paso 4 se muestran como deben de quedar las variables CLASSPATH y PATH, las copie y edite yo mismo en el fichero .bashrc. Así al abrir una nueva consola, las variables de entorno están correctamente.

    Despues de este fallo, daba problemas al arrancar el servidor:
        
    
    Osea, que cuando se debe de ingresar la contraseña del usuario. Para evitar este problema debemos de indicar la siguiente JAVA_OPTIONS, que nos permitira introducir la contraseña.
        $ $JAVA_HOME/bin/java -Dweblogic.management.allowPasswordEcho=true -Xmx1024m -XX:MaxPermSize=128m weblogic.Server
    
    Tras esto solo tendremos que acceder a la siguiente URL y empezar a disfrutar de weblogic http://localhost:7001/console

    lunes, 2 de mayo de 2011

    Parece que Tomcat no pilla las librerias de Maven

    Hoy he estado intentando desplegar mi pequeño proyecto tras instalar el nuevo Ubuntu 11. El problema es que un proyecto bien configurado y que sabía que funcionaba al intentar arrancarlo con el tomcat me salía el siguiente problema:
    java.lang.ClassNotFoundException: org.springframework.web.context.ContextLoaderListener
    Parecía que el tomcat no desplegaba correctamente el proyecto, pues estaba bien configurado. Además probando a insertar en el directorio 'webapps' de tomcat el war generado por maven, este era desplegado correctamente y sin fallos.

    Un poco desesperado por no saber que pasaba, intente desplegarlo con jetty (ya otro día contaré esta historia). Y más de lo mismo, no encuentra las librerías y es que me doy cuenta que no empaqueta ninguna librería en el 'WEB-INF/lib' del empaquetado por eclipse y pasado al jetty. Por lo que parece que el fallo mas que del servidor es del empaquetado realizado por eclipse.

    Mirando por Internet me entere de que era necesario indicarle las JavaEE dependencies al proyecto. Pero se ve que mi eclipse Helios no tiene esa opción en las preferencias del proyecto. Investigando un poco más he descubierto que lo que antes (En Ganymedes o Galileo) era 'JavaEE dependencies' ahora en Helios se llama 'Deployment Assembly'.

    Por lo que lo único que tenemos que hacer para que el eclipse empaquete correctamente el war y lo envié al servidor de desarrollo, es añadir las dependencias de maven en la opción 'Deployment Assembly' del proyecto. Si tenemos Ganymedes o Galileo sera en 'JavaEE dependencies'.

    sábado, 19 de febrero de 2011

    Porque el p*** eclipse no despliega bien ?

    Hace poco instale el nuevo ubuntu 10.10 (versión notebook, mi pc no da para mas). Y estaba usando el eclipse que se instala con el centro de software.

    El caso es que cambiando un proyecto, añadiendo nuevas librerías al mismo, me doy cuenta que el eclipse no actualiza correctamente este mismo proyecto en el work directory del tomcat. Esto es algo básico y automático y en principio no tiene porque fallar.

    En un primer momento me ha dado por cambiar donde se despliega el proyecto, pasando de ser en el plugin del tomcat del propio eclipse a indicarle que es en la carpeta webapps de tomcat. (En un primer momento estaban deshabilitado las opciones de 'server location', para desbloquearlas tuve que ir a las propiedades del servidor tomcat, y en general pulsar sobre 'switch location'). Así tampoco me desplegaba bien el proyecto.

    Así se me ocurrió, quitar el proyecto de las aplicaciones que despliega el servidor indicado en eclipse (que como he dicho es tomcat), e indicar en el maven que lo empaquetase el y lo pusiese en la carpeta de despliegue. Eso se puede hacer configurando el plugin de package en el pom.xml.
    
      org.apache.maven.plugins
      maven-war-plugin
      2.1.1
      
        /opt/apache-tomcat-6.0.32/webapps/almacen/