Receta sencilla si quieres es mover un repositorio GIT de un servidor a otro:
Primero nos aseguramos que nos colocamos sobre el branch a migrar. Supongamos que queremos que sea el 'master'.
git branch (para ver en que branch nos encontramos)
git checkout master (nos posicionamos sobre el master)
Mantenemos el remote que tenemos ahora mismo configurado. Lo que hacemos es renombrarlo a 'upstream'.
git remote rename origin upstream
Añadimos el nuevo remote en el que queremos que se encuentre el código.
git remote add origin URL_TO_NEW_REPO
Lo subimos todo. Esto puede tardar un rato, ya que se subirá también todo el histórico
git push origin master
Hacemos que nuestro remote por defecto sea el nuevo (origin), para que cada vez que hagamos 'git pull/push' se haga automáticamente sobre el nuevo servidor.
¿Tienes problemas con tu encoding y acentos en Glassfish? ¿Has puesto en todos lados UTF-8 y cuando escribes "López" en un Input y lo envías a través de un formulario recibes "López" en el servidor?
En mi caso lo he solucionado añadiendo en el fichero glassfish-web.xml la siguiente línea:
<parameter-encoding default-charset="UTF-8"/>
Si has llegado hasta aquí con este mismo problema espero que te haya ayudado, ya que yo perdí una hora por esto.
Recientemente publiqué una entrada: Aplicación CRUD con JEE7, en la que explicaba que había subido un proyecto a github: jee7-crud, con lo básico para realizar una aplicación CRUD con: JSF, EJB, JPA, JAX-RS.
Bien, acabo de actualizar jee7-crud, y le he metido herramientas básicas de testing:
JUnit
Mockito
Arquillian
Lo he preparado para que funcione con las dos herramientas de construcción de proyectos más populares actualmente: Maven y Gradle.
Este proyecto, A mi personalmente, me sirve de base para comenzar otros proyectos nuevos. Espero que os sea de alguna utilidad.
El código está basado en la siguiente entrada de Arun Gupta. Concretamente el código original se encuentra aquí. Recomiendo la lectura de la entrada entera. Me parece que hace una buena comparación entre Spring y JEE6, aunque personalmente creo que se equivoca en un aspecto. En uno de los puntos hace una comparación de rendimiento entre Glassfish+JEE6 y Glassfish+Spring. Creo que lo más fiel a la realidad sería utilizar Tomcat+Spring, ya que la aplicación programada con Spring no va a utilizar gran parte de las funcionalidades del Glassfish.
El código original viene con un sencillo CRUD sobre una entidad "Persona". Las tecnologías que se utilizan son: JSF, EJB, JPA.
El código fuente con mis modificaciones os lo podéis descargar aquí. He añadido JAX-RS para exponer un Servicio WEB REST a través de JSON.
Una vez que tengamos el código descargado podemos desplegarlo a través de nuestro IDE, o generar el WAR a través de maven (mvn package) o gradle (gradle war) y desplegarlo manualmente.
Para que la aplicación funcione será necesario configurar un Datasource en Glassfish. Tal y cómo se indica en el fichero "src/main/resources/META-INF/persistence.xml", la aplicación web se conecta al nombre JNDI "jdbc/myDataSource".
En este caso voy a explicar los pasos para crear un Datasource que se conecte a una base de datos Postgresql en Glassfish.
Una vez arrancado el glassfish vamos a http://localhost:4848 , Resources -> JDBC -> JDBC Connection Pools y pulsamos sobre el botón New.
En esta pantalla rellenamos los siguientes campos:
Pool Name: MyDatabase. Ponemos el nombre de nuestra base de datos, o el nombre que más rabia nos de.
ResourceType: javax.sql.ConnectionPoolDatasource
Database Driver Vendor: Postgresql
y pulsamos sobre Next. La parte superior de la siguiente pantalla tiene que quedar como en la siguiente imagen. No tocamos nada.
En la parte inferior tendremos que configurar las siguientes propiedades de conexión con nuestra base de datos:
User
DatabaseName
Password
ServerName
PortNumber. El puerto por defecto del postgresql es 5432
Al pulsar sobre "Finish" ya tenemos nuestro pool creado. Ahora nos falta crear la entrada JNDI que conecte con el pool que hemos creado. Para ello vamos a Resources -> JDBC -> JDBC Resources.
Creamos un nuevo Resource pulsando sobre el botón "New" y configuramos los siguientes campos:
JNDI Name: jdbc/myDatasource
Pool Name: Elegimos el nombre del pool que acabamos de crear.
Una vez configurado el Datasource la aplicación web ya debería poder desplegarse y funcionar perfectamente.
Actualización: He creado un proyecto en github (android-maven-blank): Es un proyecto plantilla con lo mínimo para que funcione con las dependencias explicadas en esta entrada.
Si te gusta tener todos tus proyectos gestionados con Maven, los proyectos de Android no iban a ser menos, pero la verdad es que Google no nos lo pone nada fácil.
A continuación voy a poner los pasos que he seguido para tener un proyecto de Android con las siguientes dependencias:
Y por supuesto, tener automatizado el proceso de generar el apk final que se subiría al play store.
Vamos a ponernos manos a la obra.
Pasos Previos
Las dependencias más complicadas de incluir van a ser precisamente las de Google, ya que no tiene un repositorio donde mantenga estos proyectos vía Maven. Por ello, lo primero que hay que hacer es descargarnos TODOS los extras del SDK Manager e instalarlos como módulos en nuestro repositorio local.
Después nos descargamos el proyecto maven-android-sdk-deployer, que se encargará de instalar todo en nuestro repositorio local. Una vez descargado nos ponemos en el directorio raíz y ejecutamos:
mvn install -P 2.2
(En mi caso pongo 2.2, porque es un SDK que tengo descargado).
Paso previo sólo si se va a utilizar Google Maps
Por lo que he visto, el proyecto maven-android-sdk-deployer despliega el módulo google-play-services, pero no lo instala correctamente porque no incluye el jar google-play-services_lib\libs\google-play-services.jar. Esto es así porque recientemente el SDK Manager ha cambiado la forma en la que distribuye este módulo. Seguro que dentro de poco el proyecto maven-android-sdk-deployer se modificará para que este paso previo no sea necesario.
Lo que he hecho para solucionarlo es instalar este jar manualmente como un módulo jar de maven:
Por supuesto que donde he puesto (PATH_SDK, NOMBRE_EMULADOR, RUTA_KEYSTORE, STOREPASS, KEYPASS, ALIAS) tendréis que poner vuestros valores.
Generar APK final para el Play Store
Una vez tenemos el pom.xml bien configurado, para generar el apk final tendremos que ejecutar:
mvn clean package -P sign
y dentro del directorio target nos generará dos apk: ${project.artifactId}.apk y ${project.artifactId}-signed-aligned.apk. El que termina en signed-aligned.apk es el que tendremos que utilizar para subir al Play Store, ya que es necesario que se le haya hecho un zip-align.
En esta entrada voy a explicar cómo montar un jar que incluya varios módulos de Maven, o eligiendo los paquetes de varios módulos.
Para ello vamos a utilizar el plugin maven-assembly-plugin. Se comporta como la mayoría de los plugins, definiendo la fase en la que queremos que se ejecute y hay que enlazar con otro fichero xml aparte donde se indique exactamente el contenido de este jar.
La forma de configurar esto dentro de nuestro pom.xml es de la siguiente manera:
Como podemos ver, tenemos que darle un id a esta ejecución y apuntar al fichero donde se encontrará la descripción del ensamblaje que vamos a realizar (por convención se guardan en el directorio src/main/assembly). Después indicamos que queremos que se realice después de la fase "package".
Generar jar juntando varios modulos
Para este primer caso nos vamos a meter en el contenido del fichero “assembly-nuevojar.xml”. Lo vamos a definir para que incluya las clases de 3 módulos nuestros:
xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> nuevojar jar
Estamos utilizando DependencySet. Con esto le indicamos que vamos a incluir en este nuevo jar el contenido de las clases de Module1, Module2 y Module3. En mi caso se encuentran bajo el mismo proyecto, y con el useProjectArtifact le indicamos que coja las de la ejecución en la que nos encontramos.
Es muy importante, que para que esto funcione las dependencias que estamos utilizando estén definidas en el pom.xml, y no vale con que estén como provided. Sino es así nos podemos encontrar con un error.
Generar jar eligiendo paquetes concretos
Para este caso vamos a generar el jar eligiendo paquetes de diferentes módulos. En mi caso, lo he hecho de una manera que no me parece nada elegante pero me funciona, siempre y cuando los módulos a coger se encuentren en el mismo proyecto que donde se va a generar el jar.
Estamos haciendo uso del fileSet en vez del dependencySet. Con esto incluimos directamente los ficheros que queremos, en este caso las clases. Como esos modulos se encuentran dentro de nuestro mismo proyecto, ya sabemos que se encuentran bajo el directorio target/classes.
