Yo uso M2Eclipse (perdón Carlos) porque:
1) estoy acostumbrado
2) creo que controlo mejor los proyectos que con q4e (quizás por
desconocimiento), especialmente los que tienen módulos
> Yo uso M2Eclipse (perdón Carlos) porque:
> 1) estoy acostumbrado
> 2) creo que controlo mejor los proyectos que con q4e (quizás por
> desconocimiento), especialmente los que tienen módulos
Yo personalmente no uso ninguno, pero ahora estoy probando (de nuevo)
la última release de Q4E.
Precisamente ahora Carlos Sanchez ha presentado:
http://us.apachecon.com/c/acus2008/sessions/51
> > Yo uso M2Eclipse (perdón Carlos) porque:
> > 1) estoy acostumbrado
> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
> > desconocimiento), especialmente los que tienen módulos
> Yo personalmente no uso ninguno, pero ahora estoy probando (de nuevo)
> la última release de Q4E.
> Precisamente ahora Carlos Sanchez ha presentado:
> http://us.apachecon.com/c/acus2008/sessions/51
yo hasta ahora nunca he utilizado ningún tipo de plugin en Eclipse. Lo
cierto es que nunca he necesitado mucha más integración que la que me
proporciona mvn eclipse:eclipse.
Hace poco probé Q4E, y lo cierto es que tiene muy buena pinta. Me gustó la
gestión de los proyectos multi-modulos, y el grafo de dependencias me parece
de una gran utilidad.
De M2Eclipse apenas lo conozco, así que no puedo opinar.
Estoy seguro que mi respuesta no te va a sacar de dudas ;).
Saludos,
dvf
El 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com> escribió:
> Yo uso M2Eclipse (perdón Carlos) porque:
> 1) estoy acostumbrado
> 2) creo que controlo mejor los proyectos que con q4e (quizás por
> desconocimiento), especialmente los que tienen módulos
Precisamente estos días he estado trabajando en Opina y he decidido
probar m2eclipse.
Creo que no sé manejar el plugin como para sacarle un máximo partido,
por ahora me apaño con las "Run configuration" que Eclipse me
proporciona.
La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
Un saludo
El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com> escribió:
> Yo uso M2Eclipse (perdón Carlos) porque:
> 1) estoy acostumbrado
> 2) creo que controlo mejor los proyectos que con q4e (quizás por
> desconocimiento), especialmente los que tienen módulos
> Precisamente estos días he estado trabajando en Opina y he decidido
> probar m2eclipse.
> Creo que no sé manejar el plugin como para sacarle un máximo partido,
> por ahora me apaño con las "Run configuration" que Eclipse me
> proporciona.
> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
> Un saludo
> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
> escribió:
> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
> > termino de decidir:
> > Yo uso M2Eclipse (perdón Carlos) porque:
> > 1) estoy acostumbrado
> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
> > desconocimiento), especialmente los que tienen módulos
> El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto <
> rec...@gmail.com> escribió:
>> Hola José:
>> Precisamente estos días he estado trabajando en Opina y he decidido
>> probar m2eclipse.
>> Creo que no sé manejar el plugin como para sacarle un máximo partido,
>> por ahora me apaño con las "Run configuration" que Eclipse me
>> proporciona.
>> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
>> Un saludo
>> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
>> escribió:
>> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
>> > termino de decidir:
>> > Yo uso M2Eclipse (perdón Carlos) porque:
>> > 1) estoy acostumbrado
>> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
>> > desconocimiento), especialmente los que tienen módulos
> El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto
> <rec...@gmail.com> escribió:
>> Hola José:
>> Precisamente estos días he estado trabajando en Opina y he decidido
>> probar m2eclipse.
>> Creo que no sé manejar el plugin como para sacarle un máximo partido,
>> por ahora me apaño con las "Run configuration" que Eclipse me
>> proporciona.
>> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
>> Un saludo
>> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
>> escribió:
>> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
>> > termino de decidir:
>> > Yo uso M2Eclipse (perdón Carlos) porque:
>> > 1) estoy acostumbrado
>> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
>> > desconocimiento), especialmente los que tienen módulos
Voy a pedir permiso a los autores del tutorial de TheServerSide y veremos si
puedo ir haciendo una traducción más o menos decente. Esto me tomará menos
que currarme un tutorial yo solito y además no creo que quedara tan bien
como éste.
Sobre Q4E, quizás Carlos Sánchez tenga también algo sobre lo que trabajar
(como tiene enchufe... ;-)
Un saludo,
JMB
El 11 de noviembre de 2008 21:16, Manuel Jesús Recena Soto <rec...@gmail.com
> Si tú preparas el tutorial de m2eclipse, yo preparo el correspondiente a
> Q4E.
> ¿Vale?
> El día 11 de noviembre de 2008 19:24, Jose M Beas
> <jose.m.b...@gmail.com> escribió:
> > Vale, me pido el tutorial de m2eclipse. :-)
> > 1saludo
> > JMB
> > El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto
> > <rec...@gmail.com> escribió:
> >> Hola José:
> >> Precisamente estos días he estado trabajando en Opina y he decidido
> >> probar m2eclipse.
> >> Creo que no sé manejar el plugin como para sacarle un máximo partido,
> >> por ahora me apaño con las "Run configuration" que Eclipse me
> >> proporciona.
> >> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
> >> Un saludo
> >> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
> >> escribió:
> >> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
> >> > termino de decidir:
> >> > Yo uso M2Eclipse (perdón Carlos) porque:
> >> > 1) estoy acostumbrado
> >> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
> >> > desconocimiento), especialmente los que tienen módulos
Bueno, he obtenido el permiso de los autores para la traducción y ya
está en marcha. Como era de esperar, voy muy despacito, así que creo
que es mejor que le podáis ir echando un vistazo y me podáis criticar
(y eventualmente ayudar). Lo he subido al área de archivos con el
nombre Introduccion_m2eclipse.zip (para que vaya con las imágenes y
todo). http://ecosistemas-software.googlegroups.com/web/Introduccion_m2eclip...
Cuando esté terminado (del todo) lo publicaré en mi blog, salvo que me
déis una mejor opción. :-)
Un saludo,
JMB
On 11 nov, 22:16, "Jose M Beas" <jose.m.b...@gmail.com> wrote:
> Voy a pedir permiso a los autores del tutorial de TheServerSide y veremos si
> puedo ir haciendo una traducción más o menos decente. Esto me tomará menos
> que currarme un tutorial yo solito y además no creo que quedara tan bien
> como éste.
> Sobre Q4E, quizás Carlos Sánchez tenga también algo sobre lo que trabajar
> (como tiene enchufe... ;-)
> Un saludo,
> JMB
> El 11 de noviembre de 2008 21:16, Manuel Jesús Recena Soto <rec...@gmail.com
> > escribió:
> > Si tú preparas el tutorial de m2eclipse, yo preparo el correspondiente a
> > Q4E.
> > ¿Vale?
> > El día 11 de noviembre de 2008 19:24, Jose M Beas
> > <jose.m.b...@gmail.com> escribió:
> > > Vale, me pido el tutorial de m2eclipse. :-)
> > > 1saludo
> > > JMB
> > > El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto
> > > <rec...@gmail.com> escribió:
> > >> Hola José:
> > >> Precisamente estos días he estado trabajando en Opina y he decidido
> > >> probar m2eclipse.
> > >> Creo que no sé manejar el plugin como para sacarle un máximo partido,
> > >> por ahora me apaño con las "Run configuration" que Eclipse me
> > >> proporciona.
> > >> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
> > >> Un saludo
> > >> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
> > >> escribió:
> > >> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
> > >> > termino de decidir:
> > >> > Yo uso M2Eclipse (perdón Carlos) porque:
> > >> > 1) estoy acostumbrado
> > >> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
> > >> > desconocimiento), especialmente los que tienen módulos
> Bueno, he obtenido el permiso de los autores para la traducción y ya
> está en marcha. Como era de esperar, voy muy despacito, así que creo
> que es mejor que le podáis ir echando un vistazo y me podáis criticar
> (y eventualmente ayudar). Lo he subido al área de archivos con el
> nombre Introduccion_m2eclipse.zip (para que vaya con las imágenes y
> todo). http://ecosistemas-software.googlegroups.com/web/Introduccion_m2eclip...
> Cuando esté terminado (del todo) lo publicaré en mi blog, salvo que me
> déis una mejor opción. :-)
>> Voy a pedir permiso a los autores del tutorial de TheServerSide y veremos si
>> puedo ir haciendo una traducción más o menos decente. Esto me tomará menos
>> que currarme un tutorial yo solito y además no creo que quedara tan bien
>> como éste.
>> Sobre Q4E, quizás Carlos Sánchez tenga también algo sobre lo que trabajar
>> (como tiene enchufe... ;-)
>> Un saludo,
>> JMB
>> El 11 de noviembre de 2008 21:16, Manuel Jesús Recena Soto <rec...@gmail.com
>> > escribió:
>> > Si tú preparas el tutorial de m2eclipse, yo preparo el correspondiente a
>> > Q4E.
>> > ¿Vale?
>> > El día 11 de noviembre de 2008 19:24, Jose M Beas
>> > <jose.m.b...@gmail.com> escribió:
>> > > Vale, me pido el tutorial de m2eclipse. :-)
>> > > 1saludo
>> > > JMB
>> > > El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto
>> > > <rec...@gmail.com> escribió:
>> > >> Hola José:
>> > >> Precisamente estos días he estado trabajando en Opina y he decidido
>> > >> probar m2eclipse.
>> > >> Creo que no sé manejar el plugin como para sacarle un máximo partido,
>> > >> por ahora me apaño con las "Run configuration" que Eclipse me
>> > >> proporciona.
>> > >> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
>> > >> Un saludo
>> > >> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
>> > >> escribió:
>> > >> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
>> > >> > termino de decidir:
>> > >> > Yo uso M2Eclipse (perdón Carlos) porque:
>> > >> > 1) estoy acostumbrado
>> > >> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
>> > >> > desconocimiento), especialmente los que tienen módulos
No no lo haré porque me costaría más traducir que contar mi
experiencia con Q4E y ver como integrarlo en el día a día.
Estoy usando la última versión desde que creamos este hilo y me gusta,
sin embargo, sigo usando la linea de comando para algunas cosas. Una
de las cosas que más me gusta, y que mi compañero Antonio Muñiz ya
comentó en su blog, es la representación gráfica de las dependencias.
Ayuda mucho.
PD: El miércoles (tarde), jueves y viernes estaré por Madrid para
asistir a ExpoQA. Lo digo por si nos podemos ver.
Un saludo
El día 23 de noviembre de 2008 20:01, Jose M Beas
<jose.m.b...@gmail.com> escribió:
> Bueno, he obtenido el permiso de los autores para la traducción y ya
> está en marcha. Como era de esperar, voy muy despacito, así que creo
> que es mejor que le podáis ir echando un vistazo y me podáis criticar
> (y eventualmente ayudar). Lo he subido al área de archivos con el
> nombre Introduccion_m2eclipse.zip (para que vaya con las imágenes y
> todo).
> http://ecosistemas-software.googlegroups.com/web/Introduccion_m2eclip...
> Cuando esté terminado (del todo) lo publicaré en mi blog, salvo que me
> déis una mejor opción. :-)
> > Voy a pedir permiso a los autores del tutorial de TheServerSide y veremos
> si
> > puedo ir haciendo una traducción más o menos decente. Esto me tomará
> menos
> > que currarme un tutorial yo solito y además no creo que quedara tan bien
> > como éste.
> > Sobre Q4E, quizás Carlos Sánchez tenga también algo sobre lo que trabajar
> > (como tiene enchufe... ;-)
> > Un saludo,
> > JMB
> > El 11 de noviembre de 2008 21:16, Manuel Jesús Recena Soto <
> rec...@gmail.com
> > > escribió:
> > > Si tú preparas el tutorial de m2eclipse, yo preparo el correspondiente
> a
> > > Q4E.
> > > ¿Vale?
> > > El día 11 de noviembre de 2008 19:24, Jose M Beas
> > > <jose.m.b...@gmail.com> escribió:
> > > > Vale, me pido el tutorial de m2eclipse. :-)
> > > > 1saludo
> > > > JMB
> > > > El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto
> > > > <rec...@gmail.com> escribió:
> > > >> Hola José:
> > > >> Precisamente estos días he estado trabajando en Opina y he decidido
> > > >> probar m2eclipse.
> > > >> Creo que no sé manejar el plugin como para sacarle un máximo
> partido,
> > > >> por ahora me apaño con las "Run configuration" que Eclipse me
> > > >> proporciona.
> > > >> La verdad es que sería genial preparar un tutorial de m2eclipse y
> Q4E.
> > > >> Un saludo
> > > >> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
> > > >> escribió:
> > > >> > Pues eso, yo he probado los dos que me parecen más conocidos y no
> me
> > > >> > termino de decidir:
> > > >> > Yo uso M2Eclipse (perdón Carlos) porque:
> > > >> > 1) estoy acostumbrado
> > > >> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
> > > >> > desconocimiento), especialmente los que tienen módulos
Hola, hace tiempo vengo siguiendo al grupo y con este thread me sentí
muy identificado.
Les cuento nuestra situación:
Este año en el trabajo hemos empezado a utilizar maven para el manejo
de los proyectos y el código, y esto nos ha traido varias ventajas
(las más importantes van por el lado de la independencia del ambiente,
la automatización de la integración continua y los test unitarios),
pero también hemos tenido que sortear muchas piedras en el camino,
alguna de las cuales todavía siguen ahi.
Actualmente estamos utilizando Eclipse (algunos 3.3 otros 3.4 -
Ganymede) con el plugin m2eclipse versión 0.9.4, no es ni ahi la
última versión del plugin debido a los problemas que hemos tenido con
las últimas versiones.
Les describo a continuación los inconvenientes más importantes que
hemos tenido a lo largo de estos últimos meses, que afectan la
productividad y la aceptación de esta tecnología entre los
desarrolladores del equipo y sobre todo entre los jefes (que dudan de
que el cambio haya sido positivo):
Update Maven Dependencies tarda siglos....
Es claro que el hecho de que en el ambiente exista un proyecto, que a
su vez tiene mas de 10 subproyectos inside, pero cada vez que se
modifica algun elemento de algun pom.xml de alguno de estos proyectos,
este proceso (UMD) que se ejecuta en background puede tardar 5 minutos
o más! Y la mayoría de las veces la espera es obligatoria, porque se
ha agregado una nueva libreria necesaria para que el código compile.
Esta espera se hace realmente insoportable cuando se deben hacer
varias modificaciones seguidas.
Errores en los proyectos (sobre todo luego del clean)
Hay veces en que, al iniciar el eclipse o al hacer un maven clean de
los proyectos, estos dan errores de compilación. Quizás sea una opción
configurable, pero me pasa seguido en que hago un maven-clean para
realizar una compilación limpia y enseguida aparecen errores de
compilación, generalmente en los test unitarios y en ese caso no es
posible ejecutarlos directamente desde el eclipse. A veces la solución
que queda es hacer un tradicional Project -> Clean.
Archivos de configuracion y .classpath se modifican todo el tiempo
Tradicionalmente, aunque no siempre, en nuestro equipo de desarrollo
tratamos de utilizar las mismas aplicaciones en el ambiente de
desarrollo (misma version de Eclipse, JDK, etc), esto permite obtener
un comportamiento homogeneo y eventualmente reproducir las fallas que
puedan surgir en el código. También permite compartir las preferencias
y configuraciones de los proyectos de eclipse
(.settings, .classpath, .project), que solemos sincronizar en el CVS.
Ahora bien, cada vez que se ejecuta el UMD los archivos .classpath y
settings se modifican, lo que significan nuevos commits sin haber
realizado ningun cambio en particular. A esta altura estamos pensando
en dejar de tener sincronizados estos archivos de configuración, pero
eso va a complicar el armado de nuevos ambientes de desarrollo.
Las últimas versiones son más lentas...
Las versiones posteriores a la 0.9.4 del plugin m2eclipse son bastante
más lentas. Es notoria la diferencia en la ejecución de cualquier
build con maven, donde el cartel "Launching Executing..." demora, y es
bastante irritante esta demora.
Creo que las características de nuestro proceso de desarrollo
(ambiente unificado, mismas plataformas, producto comercial) no son
las mejores para la aplicación de la tecnología maven, cosas que se
pueden resolver con una configuración tradicional en eclipse, que son
más manejables y el despliegue es más rápido. La resolución de las
dependencias, que es una de las ventajas que inicialmente buscábamos
al utilizar maven, es donde estamos teniendo más problemas por la
lentitud del mecanismo.
Hasta ahora solo he podido defender ante mis jefes los beneficios en
la integración continua, pero seguramente esto sea posible de alcanzar
aun sin maven en el medio, o me equivoco? Quizás ustedes me puedan dar
algunas luces sobre el tema, en las buenas prácticas de utilización de
maven o de algun otro plugin que nos evite estos problemas. De
cualquier manera me pareció buena idea compartir nuestras experiencias
porque quizás a alguien más le esté sucediendo.
Guillermo, yo también tuve un problema parecido hace tiempo.
Muchas veces, lo que nos pasaba era que tardaba muchísimo en localizar
versiones SNAPSHOT en repositorios remotos (p.ej. los de Sun), pero muchas
de estas dependencias ni tan siquiera eran necesarias, es más, había algunas
que ni tan siquiera estaban bien definidas y retrasaban el "build" tratando
de localizarlas infructuosamente. Lo ideal es tratar de depender de
artefactos que estén en el Repositorio Central de Maven y excluir lo que no
sea necesario. m2eclipse viene con Nexus, un buscador que indexa los
artefactos del Repositorio Central (o los que nosotros añadamos), y también
permite ver las dependencias.
Nosotros lo resolvimos haciendo pequeñas variaciones:
1) cuidar el ámbito (scope) de las dependencias (no todas deben ser siempre
"compile")
2) excluir las dependencias innecesarias (con "exclude")
3) utilizar un proxy para los repositorios remotos (p.ej. archiva o
artifactory)
4) tener diferentes perfiles (profile); yo aconsejaría dos para integración
continua (uno rápido, con un subconjunto de las pruebas de integración y
aceptación, y otro lento, con todos los informes y que se ejecute por las
noches, p.ej.) y otro para los desarrolladores
Aunque nada de esto tiene que ver directamente con el uso de Eclipse ni
m2eclipse. Mi consejo es que evitéis subir al SCM cualquier fichero de
configuración del IDE. (Aunque si tenéis claro que todos usáis Eclipse,
quizás podáis relajar esta regla). La idea es que el IDE no sea una fuente
de conflictos y que, siempre, el entorno "bueno" sea el de IC.
Otra cosa que se me ocurre que os pudiera estar pasando es que
inadvertidamente estéis borrando el directorio .m2/repository (o el
equivalente del plugin, que no sé si es el mismo) y estéis borrando todos
los artefactos cacheados por Maven, lo que obligaría a descargar de nuevo
todo.
El conflicto que comentas que os obliga a hacer "Project / Clean" a mi
también me ha pasado (tanto con m2eclipse como con q4e) y me ha ocurrido
cuando ejecuto Junit directamente con el plugin de Eclipse (que es mucho
mejor, claro). Revisa en tu .classpath dónde tienes configurado el "output
folder" y si tienes activado el "autorefresh" en las preferencias del
workspace.
Revisa también la versión de maven que tenéis configurada en los "launchers"
porque cuando usas la versión "embedder" puede no ser la misma que tengas
instalada en tu M2_HOME pero irá más rápido.
Espero que algo de esto te ayude.
Un saludo,
JMB
El 26 de noviembre de 2008 16:04, Guillermo Alvarez
<alvar...@gmail.com>escribió:
> Hola, hace tiempo vengo siguiendo al grupo y con este thread me sentí
> muy identificado.
> Les cuento nuestra situación:
> Este año en el trabajo hemos empezado a utilizar maven para el manejo
> de los proyectos y el código, y esto nos ha traido varias ventajas
> (las más importantes van por el lado de la independencia del ambiente,
> la automatización de la integración continua y los test unitarios),
> pero también hemos tenido que sortear muchas piedras en el camino,
> alguna de las cuales todavía siguen ahi.
> Actualmente estamos utilizando Eclipse (algunos 3.3 otros 3.4 -
> Ganymede) con el plugin m2eclipse versión 0.9.4, no es ni ahi la
> última versión del plugin debido a los problemas que hemos tenido con
> las últimas versiones.
> Les describo a continuación los inconvenientes más importantes que
> hemos tenido a lo largo de estos últimos meses, que afectan la
> productividad y la aceptación de esta tecnología entre los
> desarrolladores del equipo y sobre todo entre los jefes (que dudan de
> que el cambio haya sido positivo):
> Update Maven Dependencies tarda siglos....
> Es claro que el hecho de que en el ambiente exista un proyecto, que a
> su vez tiene mas de 10 subproyectos inside, pero cada vez que se
> modifica algun elemento de algun pom.xml de alguno de estos proyectos,
> este proceso (UMD) que se ejecuta en background puede tardar 5 minutos
> o más! Y la mayoría de las veces la espera es obligatoria, porque se
> ha agregado una nueva libreria necesaria para que el código compile.
> Esta espera se hace realmente insoportable cuando se deben hacer
> varias modificaciones seguidas.
> Errores en los proyectos (sobre todo luego del clean)
> Hay veces en que, al iniciar el eclipse o al hacer un maven clean de
> los proyectos, estos dan errores de compilación. Quizás sea una opción
> configurable, pero me pasa seguido en que hago un maven-clean para
> realizar una compilación limpia y enseguida aparecen errores de
> compilación, generalmente en los test unitarios y en ese caso no es
> posible ejecutarlos directamente desde el eclipse. A veces la solución
> que queda es hacer un tradicional Project -> Clean.
> Archivos de configuracion y .classpath se modifican todo el tiempo
> Tradicionalmente, aunque no siempre, en nuestro equipo de desarrollo
> tratamos de utilizar las mismas aplicaciones en el ambiente de
> desarrollo (misma version de Eclipse, JDK, etc), esto permite obtener
> un comportamiento homogeneo y eventualmente reproducir las fallas que
> puedan surgir en el código. También permite compartir las preferencias
> y configuraciones de los proyectos de eclipse
> (.settings, .classpath, .project), que solemos sincronizar en el CVS.
> Ahora bien, cada vez que se ejecuta el UMD los archivos .classpath y
> settings se modifican, lo que significan nuevos commits sin haber
> realizado ningun cambio en particular. A esta altura estamos pensando
> en dejar de tener sincronizados estos archivos de configuración, pero
> eso va a complicar el armado de nuevos ambientes de desarrollo.
> Las últimas versiones son más lentas...
> Las versiones posteriores a la 0.9.4 del plugin m2eclipse son bastante
> más lentas. Es notoria la diferencia en la ejecución de cualquier
> build con maven, donde el cartel "Launching Executing..." demora, y es
> bastante irritante esta demora.
> Creo que las características de nuestro proceso de desarrollo
> (ambiente unificado, mismas plataformas, producto comercial) no son
> las mejores para la aplicación de la tecnología maven, cosas que se
> pueden resolver con una configuración tradicional en eclipse, que son
> más manejables y el despliegue es más rápido. La resolución de las
> dependencias, que es una de las ventajas que inicialmente buscábamos
> al utilizar maven, es donde estamos teniendo más problemas por la
> lentitud del mecanismo.
> Hasta ahora solo he podido defender ante mis jefes los beneficios en
> la integración continua, pero seguramente esto sea posible de alcanzar
> aun sin maven en el medio, o me equivoco? Quizás ustedes me puedan dar
> algunas luces sobre el tema, en las buenas prácticas de utilización de
> maven o de algun otro plugin que nos evite estos problemas. De
> cualquier manera me pareció buena idea compartir nuestras experiencias
> porque quizás a alguien más le esté sucediendo.
> Guillermo, yo también tuve un problema parecido hace tiempo.
> Muchas veces, lo que nos pasaba era que tardaba muchísimo en localizar > versiones SNAPSHOT en repositorios remotos (p.ej. los de Sun), pero muchas > de estas dependencias ni tan siquiera eran necesarias, es más, había algunas > que ni tan siquiera estaban bien definidas y retrasaban el "build" tratando > de localizarlas infructuosamente. Lo ideal es tratar de depender de > artefactos que estén en el Repositorio Central de Maven y excluir lo que no > sea necesario. m2eclipse viene con Nexus, un buscador que indexa los > artefactos del Repositorio Central (o los que nosotros añadamos), y también > permite ver las dependencias.
Analizando el porque de la demora del "Update Maven Dependencies", no hemos podido encontrar mucho porque en la vista "Progress" lo único que aparece es un cartel "Refreshing Maven model /$Proyecto$/pom.xml" (para cada proyecto), y en la consola de maven no hay actividad salvo un esporádico: Scanned javadoc .../junit-4.4-javadoc.jar 0.0 Es como si revisara si hubo cambios para cada proyecto en particular. Intenté buscar información sobre este evento pero tampoco hay mucha en la vuelta. El siguiente paso es intentar depurar las librerías de los proyectos, como Juan sugería, pero son tantos proyectos que nos va a llevar un tiempo. Debido a la falta de info me queda la duda si en realidad lo que tarda es la resolución de dependencias o el proceso de "escaneo" de cada proyecto.
> Nosotros lo resolvimos haciendo pequeñas variaciones: > 1) cuidar el ámbito (scope) de las dependencias (no todas deben ser siempre > "compile")
En esto hemos tenido cuidado, las librerías que son brindadas por el ambiente de ejecución (servidor de aplicaciones) están con scope "provided". Sin embargo, en ocasiones nos ha traído problemas porque el m2eclipse no las agrega al build path, y la solución es cambiar a "compile" para que todo compile.
> 2) excluir las dependencias innecesarias (con "exclude") > 3) utilizar un proxy para los repositorios remotos (p.ej. archiva o > artifactory)
En general trabajamos con la opción "Offline" de maven, luego de haber bajado todas las dependencias al repositorio local (que es compartido por los desarrolladores). Probamos instalar archiva hace un tiempo pero la demora era considerable comparado con tener un repositorio local compartido.
> 4) tener diferentes perfiles (profile); yo aconsejaría dos para integración > continua (uno rápido, con un subconjunto de las pruebas de integración y > aceptación, y otro lento, con todos los informes y que se ejecute por las > noches, p.ej.) y otro para los desarrolladores
Aun no hemos probado lo de los perfiles, sin embargo no creo que afecte a la compilación aunque si al packaging.
> Aunque nada de esto tiene que ver directamente con el uso de Eclipse ni > m2eclipse. Mi consejo es que evitéis subir al SCM cualquier fichero de > configuración del IDE. (Aunque si tenéis claro que todos usáis Eclipse, > quizás podáis relajar esta regla). La idea es que el IDE no sea una fuente > de conflictos y que, siempre, el entorno "bueno" sea el de IC.
Estoy de acuerdo contigo, la experiencia está dejando claro que al utilizar maven en los proyectos, las configuraciones de eclipse no son necesarias ya que se regenerar automáticamente. IC es Integración Continua, verdad?
> Otra cosa que se me ocurre que os pudiera estar pasando es que > inadvertidamente estéis borrando el directorio .m2/repository (o el > equivalente del plugin, que no sé si es el mismo) y estéis borrando todos > los artefactos cacheados por Maven, lo que obligaría a descargar de nuevo > todo.
Como te decía más atrás, estamos utilizando un repositorio local compartido (en un directorio del servidor), por ahora es la solución más performante que hemos podido encontrar, aunque se que no nos da independencia total entre los desarrolladores, pero nos evita tener que descargar todas las librerías en cada pc. Como la mayoría de las veces estamos "Offline" no creo que venga por aqui la cosa.
> El conflicto que comentas que os obliga a hacer "Project / Clean" a mi > también me ha pasado (tanto con m2eclipse como con q4e) y me ha ocurrido > cuando ejecuto Junit directamente con el plugin de Eclipse (que es mucho > mejor, claro). Revisa en tu .classpath dónde tienes configurado el "output > folder" y si tienes activado el "autorefresh" en las preferencias del > workspace. > Revisa también la versión de maven que tenéis configurada en los > "launchers" porque cuando usas la versión "embedder" puede no ser la misma > que tengas instalada en tu M2_HOME pero irá más rápido.
La versión que utilizamos es la "Embedded". En los .classpath aparecen estas entradas: <classpathentry kind="src" output="target/classes" path="src/main/java"/> <classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debu g.ui.launcher.StandardVMType/jdk1.5.0_13"/> <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> <classpathentry kind="output" path="target/classes"/>
También activé el autorefresh, pero el problema parece ser otro. Luego del maven clean, el refresh no vuelve a hacer el build del proyecto (dentro de target las carpetas están vacias), solo se soluciona con un "eclipse-clean" del proyecto. ¿Tienes alguna otra idea que puede ser? También nos gustaría saber si los que han utilizado otros mecanismos/plugins han evitado este tipo de problemas.
¿Sólo tenéis este problema cuando hacéis el build desde Eclipse? ¿Habéis probado a ejecutar el mismo build (con las mismas opciones y todo) desde la linea de comandos?
>> Guillermo, yo también tuve un problema parecido hace tiempo.
>> Muchas veces, lo que nos pasaba era que tardaba muchísimo en localizar
>> versiones SNAPSHOT en repositorios remotos (p.ej. los de Sun), pero muchas
>> de estas dependencias ni tan siquiera eran necesarias, es más, había algunas
>> que ni tan siquiera estaban bien definidas y retrasaban el "build" tratando
>> de localizarlas infructuosamente. Lo ideal es tratar de depender de
>> artefactos que estén en el Repositorio Central de Maven y excluir lo que no
>> sea necesario. m2eclipse viene con Nexus, un buscador que indexa los
>> artefactos del Repositorio Central (o los que nosotros añadamos), y también
>> permite ver las dependencias.
> Analizando el porque de la demora del "Update Maven Dependencies", no hemos
> podido encontrar mucho porque en la vista "Progress" lo único que aparece es
> un cartel "Refreshing Maven model /$Proyecto$/pom.xml" (para cada proyecto),
> y en la consola de maven no hay actividad salvo un esporádico: Scanned
> javadoc .../junit-4.4-javadoc.jar 0.0
> Es como si revisara si hubo cambios para cada proyecto en particular.
> Intenté buscar información sobre este evento pero tampoco hay mucha en la
> vuelta. El siguiente paso es intentar depurar las librerías de los
> proyectos, como Juan sugería, pero son tantos proyectos que nos va a llevar
> un tiempo. Debido a la falta de info me queda la duda si en realidad lo que
> tarda es la resolución de dependencias o el proceso de "escaneo" de cada
> proyecto.
>> Nosotros lo resolvimos haciendo pequeñas variaciones:
>> 1) cuidar el ámbito (scope) de las dependencias (no todas deben ser
>> siempre "compile")
> En esto hemos tenido cuidado, las librerías que son brindadas por el
> ambiente de ejecución (servidor de aplicaciones) están con scope "provided".
> Sin embargo, en ocasiones nos ha traído problemas porque el m2eclipse no las
> agrega al build path, y la solución es cambiar a "compile" para que todo
> compile.
>> 2) excluir las dependencias innecesarias (con "exclude")
>> 3) utilizar un proxy para los repositorios remotos (p.ej. archiva o
>> artifactory)
> En general trabajamos con la opción "Offline" de maven, luego de haber
> bajado todas las dependencias al repositorio local (que es compartido por
> los desarrolladores). Probamos instalar archiva hace un tiempo pero la
> demora era considerable comparado con tener un repositorio local compartido.
>> 4) tener diferentes perfiles (profile); yo aconsejaría dos para
>> integración continua (uno rápido, con un subconjunto de las pruebas de
>> integración y aceptación, y otro lento, con todos los informes y que se
>> ejecute por las noches, p.ej.) y otro para los desarrolladores
> Aun no hemos probado lo de los perfiles, sin embargo no creo que afecte a la
> compilación aunque si al packaging.
>> Aunque nada de esto tiene que ver directamente con el uso de Eclipse ni
>> m2eclipse. Mi consejo es que evitéis subir al SCM cualquier fichero de
>> configuración del IDE. (Aunque si tenéis claro que todos usáis Eclipse,
>> quizás podáis relajar esta regla). La idea es que el IDE no sea una fuente
>> de conflictos y que, siempre, el entorno "bueno" sea el de IC.
> Estoy de acuerdo contigo, la experiencia está dejando claro que al utilizar
> maven en los proyectos, las configuraciones de eclipse no son necesarias ya
> que se regenerar automáticamente. IC es Integración Continua, verdad?
>> Otra cosa que se me ocurre que os pudiera estar pasando es que
>> inadvertidamente estéis borrando el directorio .m2/repository (o el
>> equivalente del plugin, que no sé si es el mismo) y estéis borrando todos
>> los artefactos cacheados por Maven, lo que obligaría a descargar de nuevo
>> todo.
> Como te decía más atrás, estamos utilizando un repositorio local compartido
> (en un directorio del servidor), por ahora es la solución más performante
> que hemos podido encontrar, aunque se que no nos da independencia total
> entre los desarrolladores, pero nos evita tener que descargar todas las
> librerías en cada pc. Como la mayoría de las veces estamos "Offline" no creo
> que venga por aqui la cosa.
No siempre podrás trabajar de forma offline, sólo tienes que pensar
que un proyecto necesite un SNAPSHOT de una librería.
Te cuento un caso real que estamos viviendo actualmente. Estamos
desarrollando una librería de acceso a datos (DAO) que vamos a
reutilizar en el resto de proyectos. Esa librería la mantiene un
desarrollo del equipo. Dado que se encuentra en una versión
0.1.0-SNAPSHOT. La librería es funcional, pero no estable. Por tanto,
se despliega en nuestro repositorio cada hora. Para que todos tengamos
los últimos cambios. Si trabajásemos de forma offline perderíamos este
modo de trabajar.
¿Y no os conviene disponer de un proxy/repository de maven? Nosotros
usamos Archiva en nuestro ecosistema.
>> El conflicto que comentas que os obliga a hacer "Project / Clean" a mi
>> también me ha pasado (tanto con m2eclipse como con q4e) y me ha ocurrido
>> cuando ejecuto Junit directamente con el plugin de Eclipse (que es mucho
>> mejor, claro). Revisa en tu .classpath dónde tienes configurado el "output
>> folder" y si tienes activado el "autorefresh" en las preferencias del
>> workspace.
>> Revisa también la versión de maven que tenéis configurada en los
>> "launchers" porque cuando usas la versión "embedder" puede no ser la misma
>> que tengas instalada en tu M2_HOME pero irá más rápido.
> La versión que utilizamos es la "Embedded". En los .classpath aparecen estas
> entradas:
> <classpathentry kind="src" output="target/classes"
> path="src/main/java"/>
> <classpathentry excluding="**" kind="src" output="target/classes"
> path="src/main/resources"/>
> <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debu g.ui.launcher.StandardVMType/jdk1.5.0_13"/>
> <classpathentry kind="con"
> path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>
> <classpathentry kind="output" path="target/classes"/>
> También activé el autorefresh, pero el problema parece ser otro. Luego del
> maven clean, el refresh no vuelve a hacer el build del proyecto (dentro de
> target las carpetas están vacias), solo se soluciona con un "eclipse-clean"
> del proyecto. ¿Tienes alguna otra idea que puede ser?
> También nos gustaría saber si los que han utilizado otros mecanismos/plugins
> han evitado este tipo de problemas.
El problema no se da exactamente en el build de maven, sino al modificar
alguna dependencia en cualquiera de los pom de los proyectos. Ahi es cuando
se inicia el proceso de "Update Maven Dependencies" que demora demasiado.
Como decía en un mensaje anterior, no creo que sea un tema de conexión al
repositorio, porque aun en modo Offline la demora persiste.
Hace unos días también estuvimos probando el plugin Q4E, y vimos que en la
ejecución de los goals es bastante más rápido que el m2eclipse. De todas
formas al iniciar el IDE empieza con un "Updating classpath container..."
tan pesado como el UMD :(
Buscando info sobre el tema encontre este thread...
Segui los pasos para poner en debug los eventos de maven, y note que, aun en
modo offline, q4e hace realiza un montón de chequeos de librerías pero no
entiendo el motivo. Les adjunto parte del log para que lo revisen,
seguramente tengan más idea que yo. Por lo menos el Q4E nos da más idea de
lo que está pasando en background.
En resumen, lamentablemente este overhead nos estan llevando a descartar la
idea de utilizar plugins de maven en Eclipse y volver a esos preciados
momentos en que todo se resolvia con un Project -> Clean :)
Gracias por todo
Saludos
Guillermo
2008/11/27 Manuel Jesús Recena Soto <rec...@gmail.com>
> Te hago un comentario entre líneas a una de las cuestiones que has
> comentado.
> El día 27 de noviembre de 2008 16:52, Guillermo Alvarez
> <alvar...@gmail.com> escribió:
> > Gracias José por tu pronta respuesta, hemos estado probando tus
> > recomendaciones y he aqui los resultados...
> > 2008/11/26 Jose M Beas <jose.m.b...@gmail.com>
> >> Guillermo, yo también tuve un problema parecido hace tiempo.
> >> Muchas veces, lo que nos pasaba era que tardaba muchísimo en localizar
> >> versiones SNAPSHOT en repositorios remotos (p.ej. los de Sun), pero
> muchas
> >> de estas dependencias ni tan siquiera eran necesarias, es más, había
> algunas
> >> que ni tan siquiera estaban bien definidas y retrasaban el "build"
> tratando
> >> de localizarlas infructuosamente. Lo ideal es tratar de depender de
> >> artefactos que estén en el Repositorio Central de Maven y excluir lo que
> no
> >> sea necesario. m2eclipse viene con Nexus, un buscador que indexa los
> >> artefactos del Repositorio Central (o los que nosotros añadamos), y
> también
> >> permite ver las dependencias.
> > Analizando el porque de la demora del "Update Maven Dependencies", no
> hemos
> > podido encontrar mucho porque en la vista "Progress" lo único que aparece
> es
> > un cartel "Refreshing Maven model /$Proyecto$/pom.xml" (para cada
> proyecto),
> > y en la consola de maven no hay actividad salvo un esporádico: Scanned
> > javadoc .../junit-4.4-javadoc.jar 0.0
> > Es como si revisara si hubo cambios para cada proyecto en particular.
> > Intenté buscar información sobre este evento pero tampoco hay mucha en la
> > vuelta. El siguiente paso es intentar depurar las librerías de los
> > proyectos, como Juan sugería, pero son tantos proyectos que nos va a
> llevar
> > un tiempo. Debido a la falta de info me queda la duda si en realidad lo
> que
> > tarda es la resolución de dependencias o el proceso de "escaneo" de cada
> > proyecto.
> >> Nosotros lo resolvimos haciendo pequeñas variaciones:
> >> 1) cuidar el ámbito (scope) de las dependencias (no todas deben ser
> >> siempre "compile")
> > En esto hemos tenido cuidado, las librerías que son brindadas por el
> > ambiente de ejecución (servidor de aplicaciones) están con scope
> "provided".
> > Sin embargo, en ocasiones nos ha traído problemas porque el m2eclipse no
> las
> > agrega al build path, y la solución es cambiar a "compile" para que todo
> > compile.
> >> 2) excluir las dependencias innecesarias (con "exclude")
> >> 3) utilizar un proxy para los repositorios remotos (p.ej. archiva o
> >> artifactory)
> > En general trabajamos con la opción "Offline" de maven, luego de haber
> > bajado todas las dependencias al repositorio local (que es compartido por
> > los desarrolladores). Probamos instalar archiva hace un tiempo pero la
> > demora era considerable comparado con tener un repositorio local
> compartido.
> >> 4) tener diferentes perfiles (profile); yo aconsejaría dos para
> >> integración continua (uno rápido, con un subconjunto de las pruebas de
> >> integración y aceptación, y otro lento, con todos los informes y que se
> >> ejecute por las noches, p.ej.) y otro para los desarrolladores
> > Aun no hemos probado lo de los perfiles, sin embargo no creo que afecte a
> la
> > compilación aunque si al packaging.
> >> Aunque nada de esto tiene que ver directamente con el uso de Eclipse ni
> >> m2eclipse. Mi consejo es que evitéis subir al SCM cualquier fichero de
> >> configuración del IDE. (Aunque si tenéis claro que todos usáis Eclipse,
> >> quizás podáis relajar esta regla). La idea es que el IDE no sea una
> fuente
> >> de conflictos y que, siempre, el entorno "bueno" sea el de IC.
> > Estoy de acuerdo contigo, la experiencia está dejando claro que al
> utilizar
> > maven en los proyectos, las configuraciones de eclipse no son necesarias
> ya
> > que se regenerar automáticamente. IC es Integración Continua, verdad?
> >> Otra cosa que se me ocurre que os pudiera estar pasando es que
> >> inadvertidamente estéis borrando el directorio .m2/repository (o el
> >> equivalente del plugin, que no sé si es el mismo) y estéis borrando
> todos
> >> los artefactos cacheados por Maven, lo que obligaría a descargar de
> nuevo
> >> todo.
> > Como te decía más atrás, estamos utilizando un repositorio local
> compartido
> > (en un directorio del servidor), por ahora es la solución más performante
> > que hemos podido encontrar, aunque se que no nos da independencia total
> > entre los desarrolladores, pero nos evita tener que descargar todas las
> > librerías en cada pc. Como la mayoría de las veces estamos "Offline" no
> creo
> > que venga por aqui la cosa.
> No siempre podrás trabajar de forma offline, sólo tienes que pensar
> que un proyecto necesite un SNAPSHOT de una librería.
> Te cuento un caso real que estamos viviendo actualmente. Estamos
> desarrollando una librería de acceso a datos (DAO) que vamos a
> reutilizar en el resto de proyectos. Esa librería la mantiene un
> desarrollo del equipo. Dado que se encuentra en una versión
> 0.1.0-SNAPSHOT. La librería es funcional, pero no estable. Por tanto,
> se despliega en nuestro repositorio cada hora. Para que todos tengamos
> los últimos cambios. Si trabajásemos de forma offline perderíamos este
> modo de trabajar.
> ¿Y no os conviene disponer de un proxy/repository de maven? Nosotros
> usamos Archiva en nuestro ecosistema.
> Un saludo
> >> El conflicto que comentas que os obliga a hacer "Project / Clean" a mi
> >> también me ha pasado (tanto con m2eclipse como con q4e) y me ha ocurrido
> >> cuando ejecuto Junit directamente con el plugin de Eclipse (que es mucho
> >> mejor, claro). Revisa en tu .classpath dónde tienes configurado el
> "output
> >> folder" y si tienes activado el "autorefresh" en las preferencias del
> >> workspace.
> >> Revisa también la versión de maven que tenéis configurada en los
> >> "launchers" porque cuando usas la versión "embedder" puede no ser la
> misma
> >> que tengas instalada en tu M2_HOME pero irá más rápido.
> > La versión que utilizamos es la "Embedded". En los .classpath aparecen
> estas
> > entradas:
> > <classpathentry kind="src" output="target/classes"
> > path="src/main/java"/>
> > <classpathentry excluding="**" kind="src" output="target/classes"
> > path="src/main/resources"/>
> > <classpathentry kind="con"
> > También activé el autorefresh, pero el problema parece ser otro. Luego
> del
> > maven clean, el refresh no vuelve a hacer el build del proyecto (dentro
> de
> > target las carpetas están vacias), solo se soluciona con un
> "eclipse-clean"
> > del proyecto. ¿Tienes alguna otra idea que puede ser?
> > También nos gustaría saber si los que han utilizado otros
> mecanismos/plugins
> > han evitado este tipo de problemas.
Aqui les envio el log, esta vez sin la opción "Offline". Coloqué el filtro
en "info" para que fuera más rápido y este es el resultado (o parte de el).
Podrán ver que el proceso inicia 11:14 y termina 11:47 :(
y cuando quieran una desconferencia en el hemisferio sur solo avisen, lugar
se consigue, :D
Bufff, no lo tengo nada claro, pero lo que se ve en el log es que el proceso
que sea trata de localizar las dependencias en el repositorio local, no
tiene éxito y entonces trata de localizarlas en el repo1.
¿Os pasa esto en una instalación nueva, fuera de vuestro entorno habitual,
sin configuraciones especiales (e.d. sin offline ni nada) y con un proyecto
tipo "hola mundo"? Lo digo por descartar que tenga que ver con alguna
configuración particular e ir tratando de acotar el problema.
A partir de que consigáis una instalación+configuración+proyecto que
funcione (revisad los logs para comprobar que no salen los reintentos), id
cambiando una sóla cosa cada vez hasta ser capaces de reproducir el problema
o llegar a una situación aceptable.
Suerte y un saludo,
JMB
El 28 de noviembre de 2008 17:54, Guillermo Alvarez
<alvar...@gmail.com>escribió:
> Aqui les envio el log, esta vez sin la opción "Offline". Coloqué el filtro
> en "info" para que fuera más rápido y este es el resultado (o parte de el).
> Podrán ver que el proceso inicia 11:14 y termina 11:47 :(
> y cuando quieran una desconferencia en el hemisferio sur solo avisen, lugar
> se consigue, :D
Creo que lo que está pasando es que no existe el POM de muchas de tus
dependencias (las que aparecen el log que adjuntas no lo tienen en repo1),
esto provoca que cada vez que compilas se intente descargar el pom y esto
tarda bastante (para cada una de las dependencias que no tienen POM).
Lo que hacemos nosotros ante esta situación es subir un POM básico a nuestro
repositorio interno (Archiva) para cada dependencia que encontramos sin POM.
Un saludo.
El 28 de noviembre de 2008 17:54, Guillermo Alvarez
<alvar...@gmail.com>escribió:
> Aqui les envio el log, esta vez sin la opción "Offline". Coloqué el filtro
> en "info" para que fuera más rápido y este es el resultado (o parte de el).
> Podrán ver que el proceso inicia 11:14 y termina 11:47 :(
> y cuando quieran una desconferencia en el hemisferio sur solo avisen, lugar
> se consigue, :D
No creáis que no he estado trabajando en la traducción del artículo de
m2eclipse, lo que pasa es que he tenido a uno de los niños con
varicela y se me ha complicado la logística. Además, he "migrado" el
artículo a un wiki http://jmbeas.wikidot.com/m2eclipse porque creo que
así es más fácil de que sea accesible y poderlo ir modificando poco a
poco.
Un saludo,
JMB
On 18 nov, 20:01, jmbeas <jose.m.b...@gmail.com> wrote:
> Bueno, he obtenido el permiso de los autores para la traducción y ya
> está en marcha. Como era de esperar, voy muy despacito, así que creo
> que es mejor que le podáis ir echando un vistazo y me podáis criticar
> (y eventualmente ayudar). Lo he subido al área de archivos con el
> nombre Introduccion_m2eclipse.zip (para que vaya con las imágenes y
> todo).http://ecosistemas-software.googlegroups.com/web/Introduccion_m2eclip...
> Cuando esté terminado (del todo) lo publicaré en mi blog, salvo que me
> déis una mejor opción. :-)
> Un saludo,
> JMB
> On 11 nov, 22:16, "Jose M Beas" <jose.m.b...@gmail.com> wrote:
> > Voy a pedir permiso a los autores del tutorial de TheServerSide y veremos si
> > puedo ir haciendo una traducción más o menos decente. Esto me tomará menos
> > que currarme un tutorial yo solito y además no creo que quedara tan bien
> > como éste.
> > Sobre Q4E, quizás Carlos Sánchez tenga también algo sobre lo que trabajar
> > (como tiene enchufe... ;-)
> > Un saludo,
> > JMB
> > El 11 de noviembre de 2008 21:16, Manuel Jesús Recena Soto <rec...@gmail.com
> > > escribió:
> > > Si tú preparas el tutorial de m2eclipse, yo preparo el correspondiente a
> > > Q4E.
> > > ¿Vale?
> > > El día 11 de noviembre de 2008 19:24, Jose M Beas
> > > <jose.m.b...@gmail.com> escribió:
> > > > Vale, me pido el tutorial de m2eclipse. :-)
> > > > 1saludo
> > > > JMB
> > > > El 11 de noviembre de 2008 18:29, Manuel Jesús Recena Soto
> > > > <rec...@gmail.com> escribió:
> > > >> Hola José:
> > > >> Precisamente estos días he estado trabajando en Opina y he decidido
> > > >> probar m2eclipse.
> > > >> Creo que no sé manejar el plugin como para sacarle un máximo partido,
> > > >> por ahora me apaño con las "Run configuration" que Eclipse me
> > > >> proporciona.
> > > >> La verdad es que sería genial preparar un tutorial de m2eclipse y Q4E.
> > > >> Un saludo
> > > >> El día 8 de noviembre de 2008 0:14, jmbeas <jose.m.b...@gmail.com>
> > > >> escribió:
> > > >> > Pues eso, yo he probado los dos que me parecen más conocidos y no me
> > > >> > termino de decidir:
> > > >> > Yo uso M2Eclipse (perdón Carlos) porque:
> > > >> > 1) estoy acostumbrado
> > > >> > 2) creo que controlo mejor los proyectos que con q4e (quizás por
> > > >> > desconocimiento), especialmente los que tienen módulos
