Primeros pasos con maven Parte I

Posted on julio 20, 2012 por admin

Desde su nacimiento Maven ha ido consolidando y a su vez aumentando su posición como herramienta de gestión y construcción de software en lenguaje Java, poco a poco quitandole terreno a otra famosa herramienta presente en el mercado desde hace mas tiempo que de seguro mucho de ustedes la habran oido mencionar Apache Ant.

A continuación les dejo unas graficas sacadas con el software de estadistica de google donde se puede observar como ha ido incrementandose el interes de Maven con respecto a Ant en distintas categorias

Además es cuestión de revisar ofertas de trabajo para ver como cada vez piden mas el conocer Maven como requisito indispensable o como poco un requisito deseado a poseer por parte del candidato. Dada esta introducción quiero compartir con ustedes lo poco que se y he aprendido de maven con la finalidad de que pueda serles de utilidad o al menos como incentivo a aprender mas de esta poderosa herramienta.

Instalación

Debemos ir al sitio web de Maven y descargar los binarios, como vamos a ir haciendo cosas sencillas les recomiendo que empecemos con la versión 3 para ir familiarizandonos con las novedades de esta nueva versión (según he leido goza de mejoras de productividad, errores, además de escribir el fichero POM en otros lenguajes no XML como groovy, ruby, scala entre otros).

NOTA: Antes de realizar los siguientes pasos de la instalación, asumimos que ya de antemano existe la variable JAVA_HOME apuntando a la ruta donde tenemos instalado nuestra versión de Java y que a su vez los binarios de Java ya han sido añadidos al PATH del sistema.

Usuarios Windows XP

Una vez descargado el software, descomprimirlo en la carpeta de preferencia, por ejemplo para usuarios windows podria ser la ruta C:\Archivos de programa\apache-maven,
Creamos las variables de entorno en panel de control->Sistema->Opciones avanzadas->variables de entorno. Alli crearemos 2 nuevas variables del sistema. La primera será M2_HOME su valor será la ruta (path) donde hallamos instalado maven p.e. C:\Archivos de programa\apache-maven\apache-maven-3.0.4. La segunda variable será M2 y su valor será %M2_HOME%\bin.
Editamos la variable del sistema PATH, y agregamos al final del contenido del valor de la variable PATH, el valor de la variable M2, de la siguiente manera:valor_variable_path;%M2%.
Probamos que los pasos anteriores se han efectuado correctamente, Por linea de comandos (inicio->ejecutar: cmd.exe) tecleamos mvn -version y deberá aparecer la información de maven, como por ejemplo la versión java, la versión maven, la ruta de instalación, etc.

Usuarios Linux/Mac Os X

Una vez descargado maven, lo extraemos en nuestro lugar de preferencia, pero podriamos utilizar la ruta /usr/local/apache-maven.
En el terminal por linea de comando, exportamos la variable M2_HOME con el valor de la ruta donde hemos instalado maven por ejemplo, export M2_HOME = /usr/local/apache-maven/apache-maven-3.0.4. De igual manera hacemos con la variable M2, de la siguiente manera, export M2=$M2_HOME/bin.
Agregamos al PATH la variable M2, de la siguiente manera, export PATH=$M2:$PATH.
Probamos que los pasos anteriores se han efectuado correctamente, Por linea de comandos tecleamos mvn -version y deberá aparecer la información de maven, como por ejemplo la versión java, la versión maven, la ruta de instalación, etc.

Configuración opcional

Si entramos en la ruta donde hemos instalado maven encontraremos el fichero settings.xml dentro de la carpeta conf, este fichero nos permite configurar aspectos adicionales, como pueden ser modificar la ruta por defecto donde se alojara nuestro repositorio o indicar una conexón proxy, entre otras cosas.

Si estamos conectados por medio de un servidor proxy sencillamente descomentamos el contenido de la etiqueta proxies y alli indicamos los valores con lo cual accedemos a conectarnos. por ejemplo

<proxies>
    <proxy>
      <id>optional</id>
      <active>true</active>
      <protocol>http</protocol>
      <username>proxyuser</username>
      <password>proxypassword</password>
      <host>proxy_hostname</host>
      <port>puerto</port>
      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
    </proxy>
</proxies>

<proxy>

<id>optional</id>

<username>proxyuser</username>

<password>proxypassword</password>

<host>proxy_hostname</host>

<port>puerto</port>

<nonProxyHosts>local.net|some.host.com</nonProxyHosts>

</proxy>

</proxies>

Por otro lado si desearamos modificar la ruta por defecto del repositorio, solo descomentariamos el contenido de la etiqueta local_repository y colocamos la ruta donde deseemos que este ubicado nuestro repositorio, por ejemplo en windows podría ser algo como esto:

<localRepository>C:\repositorio3</localRepository>

1	<localRepository>C:\repositorio3</localRepository>

Ahora que ya tenemos maven instalado, configurado y tenemos constancia de ello (habiendo efectuado las pruebas), vamos a crear nuestro primer proyecto Maven, lo haremos por linea de comandos y tecleamos lo siguiente:

mvn archetype:generate -DgroupId=com.josedeveloper.app -DartifactId=PruebaMaven -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Esta sentencia nos creara todo el esqueleto del Proyecto incluyendo un fichero de pruebas y un main (con un «Hola mundo!»), la primera vez puede que tarde un poco, ya que maven estara descargandose las ultimas versiones de los plug-ins a nuestro repositorio, incluso en el sitio web de Maven nos indican que puede que esta sentencia debamos ejecutarla en más de una oportunidad ya que pueden ocurrir time out antes de que se haya terminado la descarga (esperemos que no sea nuestro caso).

Una vez creado el proyecto veremos una carpeta de nombre PruebaMaven (o cualquier otro que hayamos utilizado) si entramos en esa carpeta nos encontraremos con el fichero pom.xml y este no es mas que el fichero que maneja la configuración de nuestro proyecto (haciendo una analogia vendria siendo algo asi como el build.xml de Ant).

Maven funciona en torno a fases, y una fase no es más que un paso dentro del ciclo de vida de construcción de un proyecto, es importante tener en cuenta que para llegar a una fase es necesario haber pasado previamente por las fases que le preceden. Las fases por defecto más comunes de un proyecto serían las siguientes:

validate: Valida que el proyecto esta correcto y dispone de la información necesaria.
compile: Compila el código fuente del proyecto.
test: Prueba el código fuente compilado haciendo uso de frameworks para pruebas unitarias (JUnit).
package: Empaqueta el código fuente compilado (por ejemplo creando un jar o war).
integration-test: Procesa y despliega el paquete dentro de un entorno de test de integración.
verify: Ejecuta los controles necesarios para verificar si el paquete es válido y cumple con los criterios de calidad.
install: Instala el paquete dentro del repositorio local, para poder usarlo como dependencia en otro proyecto.
deploy: Copia el paquete final al repositorio remoto para compartir con otros desarrolladores y proyectos.

Analizando lo anterior y volviendo a lo de las fases, nos damos cuenta que tiene mucha logica el enfoque de fases de Maven, ya que para poder probar un código, es necesario haberlo compilado de antemano, lo cual implica haber pasado por la fase compile, así como para poder instalar un proyecto como dependencia en el repositorio es necesario que el código haya sido compilado, se haya probado, luego empaquetarlo, lo que se traduce que al invocar la fase install previamente tuvo que haber pasado por las fases, compile, test, package… y asi sucesivamente.

Ahora procedamos a construir el proyecto, sencillamente ubicandonos dentro de la carpeta del proyecto, introducimos por linea de comandos, lo siguiente

mvn package

Si navegamos por la estructura de directorio veremos que en la carpeta target nos habra creado un fichero .jar, además que durante la ejecución de la ultima sentencia podemos ver como se van ejecutando las fases previas al empaquetado.

Ya empaquetado el proyecto procedemos a ejecutarlo y lo haremos también por linea de comandos introduciendo la siguiente sentencia

>java -cp .\target\PruebaMaven-1.0-SNAPSHOT.jar com.josedeveloper.app.App

Podremos ver nuestro Hola Mundo! con nuestro primer proyecto maven.

Por ultimo quizás se hayan dado cuenta que algunos warning se arrojaron por linea de comando al momento del empaquetado, eso podemos resolverlo muy facilmente agregando a nuestro fichero pom.xml la siguiente linea

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

quedando este ultimo así

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.josedeveloper.app</groupId>
  <artifactId>PruebaMaven</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>PruebaMaven</name>
  <url>http://maven.apache.org</url>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

<groupId>com.josedeveloper.app</groupId>

<artifactId>PruebaMaven</artifactId>

<version>1.0-SNAPSHOT</version>

<name>PruebaMaven</name>

<url>http://maven.apache.org</url>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

</dependencies>

</project>

Conclusión

Toparse de repente con maven en un proyecto, al principio puede ser un dolor de cabeza, genera muchas interrogantes, además que la curva de aprendizaje a mi modo de ver no es de la mas rapidas, lo cual puede que nos genere uno que otro enfado, impotencia, pero a medida que se va aprendiendo y poniendo a prueba las bondades de esta herramienta ocurre un cambio como decir el pasar del odio al amor jajajaja, esto no lo tomen como una generalización sino que es una opinion personal, pero es lo que he percibido a medida que voy avanzado con Maven, entre los beneficios (gracias a la gran cantidad de plugins) pues yo brevemente destaco el poder tener un repositorio centralizado, identificando las dependencias por sus respectivas versiones, es decir, olvidemonos de la cantidad infinita de jars repetidos en cada proyecto, además de poder utilizarlo para temas de testing e integración continua, además de poder crear esqueletos de proyectos adaptados a nuestras necesidades, ya para mi lo anteriormente expuesto ya hace que valga la pena aprender a usar la herramienta, es más si les soy sincero yo aun estoy conociendo las ventajas de usar Maven y espero en medida de lo posible poderlo compartir con ustedes. De igual manera les invito a compartir sus experiencias con maven, que otras ventajas o desventajas observan ustedes de usarlo así como compartir material de interés.

Lo nuevo en Java 7

Posted on marzo 15, 2012 por admin

Tal como dice el titulo, si deseas conocer algunas de las novedades de Java 7, descárgate de forma gratuita este ebook y accede a el con tu aplicación kindle desde cualquiera de tus dispositivos, ya sea tu computadora, teléfono móvil (celular), tablet o dispositivo kindle.

Mas libros aquí

NOTA: Amazon también proporciona una aplicación Web en HTML5 para visualizar tus ebooks, que al igual que la app nativa te sincroniza tus notas, resaltados y ultima pagina alcanzada en la lectura del libro.

Como desplegar un servicio web sin utilizar un Java EE container

Posted on febrero 25, 2012 por admin

Desde la javaSE 6 es muy sencillo la creación de servicios Web ya que las annotations incluidas (proyecto Metro) en el jsdk nos permiten que un POJO pueda fácilmente convertirse en un servicio.

NOTA: Desde javaSE 5 podíamos crear servicios web con annotations, pero para entonces el jsdk no incluía al proyecto Metro, por lo cual era necesario descargar los jar necesarios del proyecto Metro e incluirlos en nuestra aplicación.

En esta oportunidad les traigo un pequeño ejemplo de un servicio Web pero con la particularidad de que lo desplegaremos sin hacer uso del un Java EE container (contenedor de servlet, servidor de aplicaciones).

Nuestro primer paso será crear el SEI (Service Endpoint Interface), aunque no es requisito indispensable, resulta en una buena practica de programación.

package examples.helloworld;

import javax.jws.WebMethod;
import javax.jws.WebService;

//Definimos el SEI
@WebService
public interface HelloWorld {

	//Indicamos que este metodo será una operación web
	@WebMethod
	public String sayHello(String name);
}

package examples.helloworld;

import javax.jws.WebMethod;

import javax.jws.WebService;

//Definimos el SEI

@WebService

public interface HelloWorld {

//Indicamos que este metodo será una operación web

@WebMethod

public String sayHello(String name);

}

Una vez definido el SEI procedemos a realizar la implementación del servicio o lo que es lo mismo el SBI (Service Bean Implementation).

package examples.helloworld;

import javax.jws.WebService;

//Enlazamos el SBI (esta clase) con el SEI
@WebService(endpointInterface="examples.helloworld.HelloWorld")
public class HelloWorldImpl implements HelloWorld {

	@Override
	public String sayHello(String name) {
		return "Hello "+name;
	}

}

package examples.helloworld;

import javax.jws.WebService;

//Enlazamos el SBI (esta clase) con el SEI

@WebService(endpointInterface="examples.helloworld.HelloWorld")

public class HelloWorldImpl implements HelloWorld {

@Override

public String sayHello(String name) {

return "Hello "+name;

}

Ahora viene una parte que a mi me resulta interesante, creamos el Publisher, el cual no es mas que la clase encargada de crear y publicar el endPoint de nuestro servicio Web.

package examples.helloworld;

import javax.xml.ws.Endpoint;

public class HelloWorldPublisher {
	public static void main(String[ ] args) {
	      // 1st argumento URL donde se publicara el servicio
	      // 2nd argumento SIB
	      Endpoint.publish("http://127.0.0.1:9876/helloworld", new HelloWorldImpl());
	    }
}

package examples.helloworld;

import javax.xml.ws.Endpoint;

public class HelloWorldPublisher {

public static void main(String[ ] args) {

// 1st argumento URL donde se publicara el servicio

// 2nd argumento SIB

Endpoint.publish("http://127.0.0.1:9876/helloworld", new HelloWorldImpl());

}

Para aquellos que no lo sepan, el servicio Web que acabamos de crear y publicar lo hemos hecho utilizando jax-ws y por ende nuestro servicio web es del tipo SOAP.

Como comprobar que nuestro servicio esta funcionando correctamente, teniendo en cuenta que no nos arroja ningún mensaje de error por consola? Sencillamente iniciemos nuestro navegador (browser) de preferencia e introduzcamos la ruta http://localhost:9876/helloworld?wsdl ó http://127.0.0.1:9876/helloworld?wsdl y les aparecerá un mensaje como este:

Ese documento XML que hemos obtenido no es mas que el WSDL (Web Service Definition Language) que es una especie de contrato donde están definidas las operaciones y características del servicio Web.

NOTA: Los usuarios de Safari verán sencillamente una pagina en blanco, pero si revisan el código fuente de dicha pagina podrán ver el documento XML, es esta la razón por la cual he optado por utilizar Firefox.

Ahora bien, ya hemos hecho un servicio Web, lo hemos publicado e incluso hemos podido ver su WSDL, queda realizar lo más esperado, poder ejecutar y probar nuestro servicio Web, para esta labor haré uso de SoapUI una herramienta gratuita que nos permite hacer pruebas de servicios web de forma sencilla, para esto crearemos un nuevo proyecto de SoapUI y le indicamos el WSDL de nuestro servicio Web, como verán en la siguiente imagen:

Esta herramienta utilizara el WSDL para construir los sobres SOAP haciendo muy sencilla la tarea de hacer las pruebas. Para finalizar haremos una ejecución editando el XML de petición que por defecto nos elabora soapUI y le colocaremos una cadena de caracteres, en este caso he utilizado mi nombre (Uds. tienen todo el derecho de colocar el suyo/vuestro jejeje) y procedemos a pulsar el símbolo de play o triángulo de ejecución y podrán ver el mensaje de respuesta de nuestro servicio.

Aqui les dejo una imagen de la ejecución hecha por mi.

Finalmente hemos realizado un servicio Web de tipo SOAP mediante jax-ws, lo hemos desplegado sin necesidad de un servidor de aplicaciones o contenedor Java EE (lo cual tiene sus limitantes, ya que solo puede recibir una petición a la vez) y hemos fácilmente hecho pruebas de nuestro servicio con una herramienta sencilla así como también útil que es soapUI. Espero les haya sido de utilidad y les haya resultado interesante.

Sabias que el serialVersionUID en las clases Java nos previene de errores en la deserialización

Posted on febrero 24, 2012 por admin

Estoy seguro que todos aquellos que hemos programado en Java en alguna oportunidad hemos visto como nuestro IDE nos arrojaba un warning (advertencia) indicandonos que «la clase serializable nombre_clase no declara un campo serialVersionUID final estatico de tipo long» y más seguro estoy (por experiencia propia) de que sin meditarlo mucho optamos por la opción que nos daba el IDE (eclipse, netbeans o cualquier otro) para que nos resolviera el warning y asi tener nuestro código limpio de mensajes de advertencia y errores.

Ejemplo de mensaje warning de serialVersionUID

¿Qué es serialVersionUID?

Es un número de versión que posee cada clase Serializable, el cual es usado en la deserialización para verificar que el emisor y el receptor de un objeto serializado mantienen una compatibilidad en lo que a serialización se refiere con respecto a la clases que tienen cargadas (el emisor y el receptor).

¿Qué pasa si no declaro un serialVersionUID?

El proceso de serialización asocia cada clase serializable a un serialVersionUID. Si la clase no especifica un serialVersionUID el proceso de serializacion calculará un serialVersionUID por defecto, basandose en varios aspectos de la clase. Es muy recomendable que se declare un serialVersionUID en las clases serializables, ya que el calculo del serialVersoinUID es muy sensible a detalles de la clase, los cuales pueden variar entre compiladores, es decir, si trabajamos serializando/deserializando objetos y trabajamos con distintos compiladores Java podemos llegar a obtener una InvalidClassException durante el proceso de deserialización debido a discrepancias entre los serialVersionUID calculados por cada compilador. Por eso para garantizar un serialVersionUID que sea indiferente a la implementación del compilador es altamente recomendado declarar un valor explicito del serialVersionUID (de tipo long) y de ser posible que tenga el modificador de acceso private para que afecte unicamente a la clase que lo ha declarado y no a las clases hijas (subclases) que hereden de ella, forzando de alguna manera a cada clase hija a declarar su propio serialVersionUID (Ver imagen abajo).

Ejemplo de herencia de clase Serializable observando warning de serialVersionUID en clase hija

Para mas información no dejen de revisar en la API la interfaz Serializable

Como compilar código Java desde una clase Java

Posted on febrero 13, 2012 por admin

Días atras dandole un vistazo a la Java API, me encontre con una interfaz que no tenia idea que existiera y es la interfaz JavaCompiler. A continuación un ejemplo sencillo de como compilar una clase:

import java.io.IOException;

import javax.tools.JavaCompiler;
import javax.tools.ToolProvider;

public class JavaCompilerExample {
	public static void main(String args[]) throws IOException{

		//Obtenemos el compilador Java del sistema
		JavaCompiler compiler =ToolProvider.getSystemJavaCompiler();
	    //Ejecuta la compilacion
		int results = compiler.run(null, null, null, "C:/Example.java");
	    System.out.println("Success: " + (results == 0));
	}

}

import java.io.IOException;

import javax.tools.JavaCompiler;

import javax.tools.ToolProvider;

public class JavaCompilerExample {

public static void main(String args[]) throws IOException{

//Obtenemos el compilador Java del sistema

JavaCompiler compiler =ToolProvider.getSystemJavaCompiler();

//Ejecuta la compilacion

int results = compiler.run(null, null, null, "C:/Example.java");

System.out.println("Success: " + (results == 0));

}

Para el ejemplo anteriormente mostrado, asumimos que hemos codificado una clase y ubicada en c:/Example.java. Como mi idea es demostrar como compilar, le dejo a ustedes la tarea de crear una clase cualquiera, con y sin errores para poder observar la salida de la ejecución de este programa.

Brevemente comento del código.

Clase ToolProvider, disponible desde la versión 6, esta clase nos permite obtener proveedores de compiladores.
Invocación del método run, método heredado de la interfaz Tool (presente desde la versión 6 de Java), es una interfaz utilizada para invocar programas, y en nuestro caso la utilizamos para la invocación del compilador. Incluso podríamos obtener las versiones soportadas por la herramienta invocando el método getSourceVersions();

La anterior no es la única forma de poder llevar a cabo la compilación, he aquí otro ejemplo, pero en este caso usando métodos propios de la interfaz JavaCompiler.

import java.io.File;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;

import javax.tools.JavaCompiler;
import javax.tools.JavaFileObject;
import javax.tools.StandardJavaFileManager;
import javax.tools.ToolProvider;
import javax.tools.JavaCompiler.CompilationTask;

public class JavaCompilerExample2 {

	public static void main(String args[]) throws IOException{

		//Obtenemos el compilador Java del sistema
		JavaCompiler compiler =ToolProvider.getSystemJavaCompiler();
		String sourceFile = "C:/Example.java";
	    //Obtenemos manejador estandar de ficheros
		StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null);

	    List sourceFileList = new ArrayList();
	    sourceFileList.add(new File(sourceFile));
	    Iterable compilationUnits = fileManager
	        .getJavaFileObjectsFromFiles(sourceFileList);
	    //Obtenemos la tarea de compilación a ejecutar posteriormente
	    CompilationTask task = compiler.getTask(null, fileManager, null, null, null, compilationUnits);
	    //Ejecutamos la tarea
	    boolean result = task.call();
	    if (result) 
	      System.out.println("La compilación ha sido exitosa");
	    else 
	      System.out.println("La compilación ha fallado");

	    fileManager.close();
	}

}

import java.io.File;

import java.io.IOException;

import java.util.ArrayList;

import java.util.List;

import javax.tools.JavaCompiler;

import javax.tools.JavaFileObject;

import javax.tools.StandardJavaFileManager;

import javax.tools.ToolProvider;

import javax.tools.JavaCompiler.CompilationTask;

public class JavaCompilerExample2 {

public static void main(String args[]) throws IOException{

//Obtenemos el compilador Java del sistema

JavaCompiler compiler =ToolProvider.getSystemJavaCompiler();

String sourceFile = "C:/Example.java";

//Obtenemos manejador estandar de ficheros

StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null);

List sourceFileList = new ArrayList();

sourceFileList.add(new File(sourceFile));

Iterable compilationUnits = fileManager

.getJavaFileObjectsFromFiles(sourceFileList);

//Obtenemos la tarea de compilación a ejecutar posteriormente

CompilationTask task = compiler.getTask(null, fileManager, null, null, null, compilationUnits);

//Ejecutamos la tarea

boolean result = task.call();

if (result)

System.out.println("La compilación ha sido exitosa");

else

System.out.println("La compilación ha fallado");

fileManager.close();

}

Esta ultima forma de llevar a cabo la compilación, particularmente es de mi preferencia ya que nos permite mejorar en rendimiento, en el caso de que llevemos a cabo la compilación de un grupo de ficheros (archivos) mientras reutilicemos el gestor de archivos, además de poder pasarle de una forma mas ordenada las opciones de compilación.

NOTA: En este segundo ejemplo también dejo de parte de ustedes la creación del fichero a compilar (C:/Example.java), que en este caso he hecho uso del mismo en ambos ejemplos.

espero les pueda ser de utilidad, incluso podríamos hasta crearnos nuestro propio IDE, donde compilemos y a su vez nos muestre los mensajes de error en caso de haberlos.

El Blog de Jose

Blog de tecnología, software y programación

Archivo de la categoría: programación

Primeros pasos con maven Parte I

Lo nuevo en Java 7

Como desplegar un servicio web sin utilizar un Java EE container

Sabias que el serialVersionUID en las clases Java nos previene de errores en la deserialización

Como compilar código Java desde una clase Java

Uso de cookies