Para instalar el jar en tu repositorio local:
[maven-home]/mvn install:install-file -Dfile=XXXX -DgroupId=XXXX -DartifactId=XXXX -Dversion=XXXX -Dpackaging=jar
Donde en Dfile hay que poner la ruta al jar.

Para instalar en el repositorio interno privado (ver Maven: 02 – Conceptos):
[maven-home]/mvn deploy:deploy-file -Dfile=XXXX -DgroupId=XXXX -DartifactId=XXXX -Dversion=XXXX -Dpackaging=jar -DrepositoryId=release-repository -Durl=ftp://XXXX/maven-repository-release

Donde -DrepositoryId debe coincidir con el correspondiente en el C:\Users\pepe\.m2\settings.xml y -Durl debe ser la url del repositorio.

Para ejecutar este último comando me encontré con varios problemas para los cuales me fue difícil encontrar la solución porque no daba errores descriptivos.
Tuve que copiar a mano estos dos jares:

• C:\Users\pepe\.m2\repository\org\apache\maven\wagon\wagon-ftp\2.10\wagon-ftp-2.10.jar a [maven-home]/lib
• C:\Users\pepe\.m2\repository\commons-net\commons-net\3.1\commons-net-3.1.jar a [maven-home]/lib

Si no tuvieras el commons-net-3.1.jar (u otras versiones supongo que valdrán) la tendrás que conseguir, yo la tenía porque la había usado como dependencia de algúnn proyecto.

Instalar el Maven no es más que bajárselo de https://maven.apache.org/download.cgi y descomprimirlo a una carpeta.
Como no me gusta tocar el JAVA_HOME ni el PATH, ya que puede afectar a otras aplicaciones, lo único que hice fue definir el JAVA_HOME en el mvn.cmd con
set JAVA_HOME=C:/PROGRA~1/Java/jdk1.8.0_65
Y los comandos los ejecuto con la ruta completa.
Por [maven_home] entiendo hasta la carpeta bin de lo que has descomprimido. Si tú has tocado el path ejecutarás el comando sin poner toda la ruta.

Para comprobar que funciona:
[maven_home]/mvn –version

Para crear un proyecto:

• creas la carpeta
• te metes dentro
• ejecutas [maven_home]/mvn archetype:generate
• respondes a las preguntas, entre ellas el id de archetype, que por lo que he visto la webapp-archetype (o la que tú quieras) no tiene siempre el mismo número, hay que buscar el número que le corresponde entre todo el texto que te habrá sacado la consola.

Con eso ya se crea la estructura básica del proyecto.

Una vez que has creado los java sigues con las fases del flujo.
Todos estos comandos debes ejecutarlos dentro del directorio que te ha creado con el nombre del artifact-id.

Para compilar:
[maven_home]/mvn compile

Instalar en tu repositorio local:
[maven_home]/mvn install

Deploy (instalar en los repositorios privados, ver “Maven: 02 – Conceptos”):
[maven_home]/mvn deploy

Si tu proyecto genera un war y lo quieres probar en el tomcat debes hacer el war con un package:
[maven_home]/mvn package
Y después copias el war del directorio target al webapps del tomcat.

Eclipse trae su propio maven, no necesitas instalar el maven por tu cuenta.

Los proyectos nuevos los creo así, aunque se pueden crear en el workspace:

• Creo la carpeta donde va estar el proyecto, por ejemplo “miproyecto”
• y en el eclipse voy haciendo lo siguiente

Con esto ya tengo el proyecto, ahora creo por ejemplo un package y una clase dentro de la carpeta java.

Ahora vamos a ver cómo hago las fases que expliqué en el post Maven: 03 – Flujo de trabajo”

Para compilar no hace falta hacer nada puesto que por defecto el eclipse va a compilar las clases de forma automática al guardar una modificación, pero puedes forzarlo con un “Proyect – clean”

Install:

Realmente creo que si tienes todos los proyectos configurados en el eclipse no es necesario que ejecutes un install para que se genere en tu repositorio local, siempre que desde otro proyecto vayas a usar la última versión, ya que el eclipse detectará que lo tienes en el eclipse y en vez de usar las clases que haya en el repositorio local lo que hará será “linkar” a las clases del proyecto dependiente.
Me explico:
Supongamos que el proyecto A tiene como dependencia al protecto B, es decir, el proyecto A usa las clases del proyecto B.
Pues bien, si la versión actual del proyecto B es la 2.0 y en el proyecto A quieres usar esa versión, no haría falta que hagas un install del proyecto B, puesto que si tienes ambos proyectos en el eclipse, lo que hará éste será linkar en el proyecto A las clases del proyecto B.
Pero sin embargo si en el proyecto A quieres usar la versión 1.1 del proyecto B sí que tenías que haber hecho un install del proyecto B con esa versión (cosa que probablemente hayas hecho porque habrás hecho un deploy de la 1.1 y al hacer un deploy se hace también un install).

Deploy:

Con esto publicas el snapshot o el release en los repositorios internos privados (Ver Maven: 02 – Conceptos) para que los pueda usar otro programador.

Package:

Si tu proyecto genera un war y lo quieres probar en el tomcat debes hacer el war con un package

Y después copiar el war del directorio target al webapps del tomcat.

Supongamos que voy a hacer cambios en la programación del proyecto A del cual depende un proyecto B.
Actualmente según el pom.xml del proyecto A, está en la versión 2.0.

• Lo primero que hago es modificar el pom.xml del proyecto A para decir que la versión pasa a ser la 2.1-SNAPSHOT.
• Después paso a hacer las modificaciones en el código java del proyecto A, las cuales por ahora no se ven en el proyecto B.
• Una vez que quieres probar las modificaciones del proyecto A en el proyecto B, tienes que hacer un install del proyecto A, lo cual te lo generará en tu repositorio local para que esté disponible para otros proyectos.

Para probar la versión 2.1-SNAPSHOT del proyecto A en el proyecto B hacemos lo siguiente:

• modificar el pom.xml del proyecto B. Supongamos que pasa de la versión 3.3 a la 3.4-SNAPSHOT
• modificamos las dependencias del pom.xml del proyecto B para decirle que tire de la versión 2.1-SNAPSHOT del proyecto A
• modificamos el código y probamos

Una vez que damos las pruebas por bueno haríamos lo siguiente:

• modificar el pom.xml del proyecto A para que pase a ser la 2.1, sin SNAPSHOT
• ejecutar un deploy del proyecto A para que se genere la 2.1 en el repositorio privado de releasses y esté accesible a cualquier otro programador.
• modificar el pom.xml del proyecto B para que pase a ser la 3.4 y también las dependencias para que tire de la versión 2.1 del proyecto A

Nota:
Si hubiéramos querido que otro programador probase la 2.1-SNAPSHOT habríamos hecho un deploy mientras estaba en 2.1-SNAPSHOT y se habría generado en el repositorio privado de snapshots, estando disponible para el resto de programadores.

Después están los repositorios en los que publicas los cambios para compartirlos con el resto de tu equipo, y que en principio deben ser repositorios privados dentro de una máquina de tu empresa, a la que tengan acceso todos los equipos. Esto sólo es necesario si trabajas en un equipo, si trabajas solo no es necesario.
A estos repositorios los llamo “repositorios privados” y son dos, uno para publicar los snapshots (desarrollos en curso) y los releases (desarrollos finales).
En mi caso he configurado estos repositorios privados con un simple servidor ftp. Se pueden usar otros métodos e incluso tener un software gestor de repositorios, pero no sé lo que aportan.

Si yo por ejemplo voy a tocar un proyecto que está en la versión 2.0, mientras lo modifico le pongo como versión la 2.1-SNAPSHOT.
Cuando ejecutas un install lo que haces es ponerlo en tu repositorio local para poder usarlo tú mismo en otro proyecto.
Si ejecutas un deploy lo que haces es ponerlo en los snapshots de los repositorios privados. Esto sólo es necesario si quieres que el resto del equipo vea tus cambios mientras están en snapshot.
Cuando das por buenos los cambios pones la versión a la 2.1 y ejecutas un deploy para poner la versión definitiva en los releases de los repositorios privados para que cualquiera del equipo pueda usar esa versión.

Por último están los repositorios públicos, que es de donde se baja las dependencias de librerías de terceros. Por defecto está el repositorio de Maven, que es donde estará casi todo lo que necesites, pero también puede darse el caso de librerías que no estén en el repositorio de Maven y tengas que configurar otros repositorios.

Sin Maven, si necesitas una funcionalidad que te proporciona el jar XXXX.jar, te tienes que bajar ese jar de donde corresponda y ponerlo en el lib de tu proyecto. Si además ese XXXX.jar utiliza los jares YYYY.jar y ZZZZ.jar, lo tienes que saber, bajártelos e incluirlos asimismo en el lib de tu proyecto.
Si lo que necesitas es en un proyecto tuyo XXXX usar las clases de otro proyecto tuyo YYYY tienes que generar un jar con las clases del YYYY y meterlas en el lib del proyecto XXXX y meter ese jar en el war del XXXX, lo cual es un poco engorroso.

Todo esto está mejor gestionado con Maven. Para un proyecto defines las dependencias que tiene con otros jares o con otros proyectos tuyos y él se ocupa de gestionarlo analizando transitivamente las dependencias de los proyectos y solucionando posibles conflictos. También se ocupa de generar el jar o el war, generarlos con diferentes versiones y permite compartir la programación entre los diferentes programadores mientras se está en desarrollo.

Para hacer todo esto Maven usa lo que llama repositorios, de los que hablaré en futuros artículos.

People at Openx use “Distributed Statistics” as an option to scale the service, but in my opinion the documentation is confuse or wrong, as you can see at this message I wrote as “raistlink”.

Distributed Statistics works like this (as I configured):

• both computers serve banners
• only one of them (or another aditional computer) works also as the admin. I will call “master” to the admin computer and “slave” to the other.
• only one computer executes the maintenance process that calculates the probability of the zones
• the replication makes the slave machine revieve those probalities
• the slave machine sends it’s activity to the master executing the maintenance-distributed instead of maintenance

It’s mandatory that you configure crones in the way that when the hourly execution of the maintenance process at the master is running, the activity from the slave has been recieved, in other case this activity will be lost. That’s why, as we will see in a moment, the master executes the maintenance process at the minute 15 everu hour and the slave executes the maintenance-distributed every five minutes.

Well, I got it at the end so I’m going to explain a bit how I did it.

The start point is two computers under a balancer serving banners under the same url, lets say my.adserver.com.

Master:

• Stop apache
• be sure maintenance is not running and stop the cron
• Stop mysql
• Set this at my.conf

server-id = 1
log-bin=mysql-bin

• Start mysql
• GRANT REPLICATION SLAVE ON *.* TO ’slave_user’@'%’ IDENTIFIED BY ‘XXXX’;

where XXXX is the password used by the slave at replication for connecting to the master.

• GRANT ALL PRIVILEGES ON *.* TO ‘root’@'%’ IDENTIFIED BY ‘YYYY’;

where YYYY is the password used by the slave in order to send its stats to the master
As you can see you can use two different passwords, no problem.

• FLUSH PRIVILEGES;
• show master status. TAKE NOTE OF THESE VALUES, YOU’LL NEED THEM AFTER

mysql-bin.000001 | 417

• make a dump

mysqldump -u root -p –databases openx_2_8_10 > /tmp/openx_2_8_10-201302071719.sql

• start apache
• execute once again show master status for testing purposes

mysql-bin.000001 | 24995895
the number has changed, so the master is replicating

Slave:

• drop openx database
• load the master dump at slave

mysql -u root -pXXXX < "/tmp/openx_2_8_10-201302071719.sql"

• execute these alter commands at openx database

ALTER TABLE ox_data_raw_ad_click ENGINE=MyISAM;
ALTER TABLE ox_data_raw_ad_impression ENGINE=MyISAM;
ALTER TABLE ox_data_raw_ad_request ENGINE=MyISAM;
ALTER TABLE ox_data_raw_tracker_impression ENGINE=MyISAM;
ALTER TABLE ox_data_raw_tracker_variable_value ENGINE=MyISAM;
In fact I don’t see that the system use this tables but…

• Set these values at my.conf

server-id = 2
log-bin=mysql-bin
(is order to work as a master if needed)
replicate-wild-ignore-table=openx_2_8_10.%data_%
replicate-wild-ignore-table=openx_2_8_10.%tmp_%
replicate-wild-ignore-table=openx_2_8_10.%lb_local%
replicate-wild-ignore-table=mysql.%
replicate-wild-ignore-table=openx_2_8_10.%ox_log_maintenance_priority% (because of a problem a had later)
replicate-wild-ignore-table=openx_2_8_10.%ox_session% (because of a problem a had later)

• start mysql
• check if the slave can access the master whith this command for example

mysqldump –host=host_master -u root -pYYYY –databases openx_2_8_10 > /tmp/openx_2_8_10-201302080959.sql

• STOP SLAVE;
• CHANGE MASTER TO MASTER_HOST=’host_master’, MASTER_USER=’slave_user’, MASTER_PASSWORD=’XXXX’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=417;

(use the values noted before)

• START SLAVE;
• SHOW SLAVE STATUS

As you can see, each time you execute this command, you obtain different values. When this values are the same than the master you will be synchronized.

Until now I’ve configured replication. The next thing is to set the slave to work as a delivery box, that is, it doesn’t work as admin and it send its activity (stats) to the master.

Master:

• If your domain is for example my.adserver.com then you have to create a cname at you domain provider for admin.my.adserver.com pointing to the master computer. I made the master to work as admin and serving banners at the same time.
• Disable automatic maintenance at the master from the admin console.
• configuration –> global settings –> Banner Delivery Settings –> “Admin Interface URL”

change my.adserver.com for admin.my.adserver.com
the system redirects to the new url.

• change tha maintenance cron to execute every hour at minute 15

Slave:

• Make these changes at openx conf file by hand
  1. set enabled at [ui] empty
  2. set enabled at [lb] to 1
  3. at [database] section set the local database. (It already was)
  4. at [lb] section set the master database

  type=mysql
  host=host_master
  socket=
  port=3306
  username=root
  password=YYYY
  name=openx_2_8_10

  5. change operationInterval at the slave in order to the maintenance-distributed be excecuted every 5 min.
• change maintenance-distributed permissions

chmod 777 [openx_home]/scripts/maintenance/maintenance-distributed.php

• set maintenance-distributed cron every 5 min.

You can add more slaves following the same instruccions or you can generate a new dump and set the new slave “listening from this point”, that is, from a new show master status.

La gente de Openx tiene “Distributed Statistics” como opción para escalar el servicio, pero en mi opinión tienen la documentación un poco confusa, cuando no equivocada, como se puede ver en este mensaje que escribí yo mismo como “raistlink”.

El sistema de Distributed Statistics funciona así resumidamente (como yo lo he montado):

• las dos máquinas sirven banners
• sólo una de ellas (u otra adicional) además es el admin. A la que hace de admin la llamaré maestra y a la otra esclava.
• sólo la máquina maestra ejecuta el maintenance que calcula las probabilidades de las zonas
• la replicación hace que la esclava coja esas probabilidades
• la esclava vuelca su actividad en el maestro ejecutando el maintenance-distributed en lugar del maintenance

Es fundamental que se configuren los crones de manera que cuando se ejecuta el maintenance de cada hora se haya volcado toda la actividad de la esclava porque si no esa actividad se perderá, por eso como veremos luego el maintenance en la maestra se ejecuta a las y cuarto y el maintenance-distributed en la esclava cada cinco minutos.

Pues bien, al final lo conseguí así que voy a explicar un poco lo que hice.

Partimos de dos máquinas independientes que están bajo un balanceador sirviendo banners bajo la misma url, por ejemplo my.adserver.com

En el maestro:

• parar el apache
• asegurarme de que no está el maintenance corriendo y quitar el cron
• parar el mysql
• poner en el my.conf

server-id = 1
log-bin=mysql-bin

• arrancar mysql
• GRANT REPLICATION SLAVE ON *.* TO ’slave_user’@'%’ IDENTIFIED BY ‘XXXX’;

donde XXX es la contraseña con la que accederá el mysql esclavo para la replicación

• GRANT ALL PRIVILEGES ON *.* TO ‘root’@'%’ IDENTIFIED BY ‘YYYY’;

donde YYYY es la contraseña con la que accederá el mysql esclavo para volcar sus estadísticas en el maestro.
Ojo hay una contraseña para el la replicación y otra para volcar los datos desde el openx, no debería haber problema.

• FLUSH PRIVILEGES;
• hacer un show master status. ÉSTE ES EL QUE TENDRÉ QUE USAR LUEGO

mysql-bin.000001 | 417

• hacer un dump

mysqldump -u root -p –databases openx_2_8_10 > /tmp/openx_2_8_10-201302071719.sql

• arrancar apache
• volver a hacer un show master status por curiosidad

mysql-bin.000001 | 24995895
se ve que está replicando porque ha cambiado el número

En el esclavo:

• eliminar base de datos de openx
• volcar el dump del master

mysql -u root -pXXXX < "/tmp/openx_2_8_10-201302071719.sql"

• ejecutar estos alter en la bbdd de datos del openx.

ALTER TABLE ox_data_raw_ad_click ENGINE=MyISAM;
ALTER TABLE ox_data_raw_ad_impression ENGINE=MyISAM;
ALTER TABLE ox_data_raw_ad_request ENGINE=MyISAM;
ALTER TABLE ox_data_raw_tracker_impression ENGINE=MyISAM;
ALTER TABLE ox_data_raw_tracker_variable_value ENGINE=MyISAM;
Realmente yo estas tablas raw yo no he visto que se usen, pero bueno, a lo mejor sí y se purgan en seguida.

• poner en el my.conf

server-id = 2
log-bin=mysql-bin
para que pudiera funcionar como maestro.
replicate-wild-ignore-table=openx_2_8_10.%data_%
replicate-wild-ignore-table=openx_2_8_10.%tmp_%
replicate-wild-ignore-table=openx_2_8_10.%lb_local%
replicate-wild-ignore-table=mysql.%
replicate-wild-ignore-table=openx_2_8_10.%ox_log_maintenance_priority% (por un problema que tuve luego)
replicate-wild-ignore-table=openx_2_8_10.%ox_session% (por un problema que tuve luego)

• arrancar el mysql
• comprobar si se puede acceder al mysql del maestro con esto

mysqldump –host=host_del_master -u root -pYYYY –databases openx_2_8_10 > /tmp/openx_2_8_10-201302080959.sql

• STOP SLAVE;
• CHANGE MASTER TO MASTER_HOST=’host_del_master’, MASTER_USER=’slave_user’, MASTER_PASSWORD=’XXXX’, MASTER_LOG_FILE=’mysql-bin.000001′, MASTER_LOG_POS=417;

(con los valores que dio en los pasos anteriores, ya están puestos)

• START SLAVE;
• SHOW SLAVE STATUS

Se ve que cada vez que lo ejecuto pone que va por un archivo diferente. Cuando ponga lo mismo que el show master status del maestro es que lo ha cogido ya todo. En muy poquito tiempo lo ha hecho.

Hasta aquí he configurado la replicación. Lo siguiente va a ser poner a funcionar el openx como delivery box en la esclava, es decir, que no funcione como admin y que vuelque su actividad (estadísticas) en el maestro.

En la maestra:

• Si por ejemplo tu dominio es my.adserver.com crear un cname en el registrador de dominios para admin.my.adserver.com que apunte a la máquina maestra. Yo hice que la máquina maestra funcione como admin y sirviendo banners al mismo tiempo.
• desactivar el automatic maintenance en el maestro desde el admin
• configuration –> global settings –> Banner Delivery Settings –> “Admin Interface URL”

cambiar my.adserver.com por admin.my.adserver.com
Él solo me redirije de la vieja a la nueva

• cambiar el cron del maintenance en el maestro para que se ejecute a las y cuarto

En la esclava:

• Hacer estos cambios en el conf de openx a mano
  1. poner el enabled del [ui] vacío
  2. poner el enabled del [lb] a 1
  3. en la sección [database] poner la bbdd local. (ya estaba)
  4. en la sección [lb] poner la bbdd maestra

  type=mysql
  host=host_del_master
  socket=
  port=3306
  username=root
  password=YYYY
  name=openx_2_8_10

  5. modificar el operationInterval en el esclavo para poder ejecutar el maintenance-distributed más a menudo, cada 5 min.
• cambiar permisos al maintenance-distributed

chmod 777 [openx_home]/scripts/maintenance/maintenance-distributed.php

• poner cron del maintenance-distributed cada 5 min

Para futuros esclavos se pueden seguir estas mismas intrucciones tal cual o generar un nuevo dump y poner el nuevo esclavo a “escuchar desde otro punto”, es decir, a un nuevo show master status.

Hace poco un amigo me regaló el libro Ingeniería de Software Ágil. El subtítulo es “un libro contra las raíces de la precariedad laboral en el sector de los servicios de software”.

Como programador, analista-programador, desarrollador de software o como se quiera llamar, me siento totalmente identificado con las críticas que hace a las metodologías actuales, la desconsideración de la labor de programación, las empresas consultoras…

El título puede llevar a engaño, ya que uno puede esperar el típico manual sobre metodologías de moda actualmente como Scrum, Extremme Programming u otras, pero no tiene nada que ver. El libro aboga por estas metodologías sí, pero no es un manual ni habla prácticamente de ellas. El libro más bien es una crítica al sistema actual, a la gente que piensa que la programación simplemente es poner un ladrillo encima de otro, que es una actividad de construcción y no de diseño o arte, que es un trabajo menor que no debe realizar un ingeniero…

A juicio del autor todos los problemas del sector vienen por este tipo de consideraciones sobre el trabajo de un programador, que llevan a las empresas a contratar personal poco cualificado y en cantidades ingentes, con la errónea creencia de que cuanta más gente más rápido se terminará el proyecto, cuando probablemente sea al contrario.

Cuestiona también la habitual gestión de proyectos basada en la división de las actividades de análisis, diseño, construcción y pruebas entre distintos grupos de personas, con distintos niveles jerárquicos de responsabilidad, mediante un proceso secuencial y dentro de sistemas formales documentalmente pesados.

Recomiendo su lectura a cualquier persona que esté en el mundo del desarrollo de software de alguna manera: programadores, empresarios con necesidad de equipos técnicos…

Web del libro y blog del autor: www.ingsoftagil.com
Comprar el libro