¿Ha llegado el momento de abandonar Spring y pasarse a Java EE 6?
AbrahamYa nos planteamos esta pregunta hace aproximadamente un año, y en aquel momento no pareció resonar demasiado con la comunidad. Pero desde entonces de un modo continuo mi feed de RSS me muestra más artículos donde se habla de migrar aplicaciones Spring a Java EE 6, o de simplemente dejar Spring como stack empresarial y volver a Java EE.
El último de estos artículos es de Java Code Geeks. El artículo cuenta una experiencia de un proyecto en el cual un prototipo inicial se hizo empleando Spring v3. Antes de desarrollar la aplicación final, se plantearon dos preguntas:
- ¿Podemos hacer en Java EE 6 todo lo que podemos hacer con Spring?
- ¿Podemos hacerlo de un modo tan sencillo como se hace en Spring?
Según el autor, la respuesta a ambas preguntas es sí. Por lo que la versión final de la aplicación se hizo con Java EE. En el artículo, el autor muestra con ejemplos de código como se consiguen diferentes acciones en Spring y Java EE (inyección de dependencias, uso de JMS, gestión de transacciones y uso de servicios web REST). Es difícil argumentar que una u otra solución son significativamente superiores.
Su conclusión final es que decir que los desarrollos con Spring son más sencillos y más ligeros que en Java EE no es por lo general es cierto.
Este es sólo el último de los artículos de este tipo en llegar a mi feed. Aquí tenéis otros:
- Why I will use Java EE (JEE, and not J2EE) instead of Spring in new Enterprise Java Projects in 2012
- Migrating Spring to Java EE 6
- Migrating Spring to Java EE 6 Article Series
- Spring to Java EE – A Migration Experience
- Migrating Spring Applications to Java EE 6
Aunque sea un tanto subjetivo, mi impresión es que en el último año desde que publicamos la noticia original de javaHispano este tipo de artículos llegan con más frecuencia a mi feed.
Nadie niega que Spring ha tenido una gran influencia dentro de Java EE y le debemos mucho. Pero ¿Con Java EE 6 ya no hace falta Spring y según va habiendo servidores de aplicaciones que soportan Java EE 6 la gente está abandonando el framework de SpringSource? ¿O todavía hay motivos para seguir usando Spring?
Hagamos una pequeña encuesta al respecto. En los comentarios de la noticia podéis explicar vuestras razones sobre por qué es Spring sigue siendo relevante, o por qué ya no lo es.
Reader Comments (23)
Hola,
yo realmente uso Spring por el módulo Spring MVC. Vale que puedes usar Struts o cualquier otro framework con JavaEE 6, pero el artículo precisamente habla de usar JavaEE 6 a pelo.
Corregidme si me equivoco, pero creo que JavaEE 6 no es comparable a los frameworks en la capa de presentación, quiero decir, no tiene cosas como binding (creación de objetos a partir de los datos de un formulario), validación, variables en URLs.
Hola,
Entonces, ¿para que cambiar? ¿por qué hacer un esfuerzo para cambiar a algo que es prácticamente igual?
Mi opinión es que tanto Spring como Java EE todavía no son tan productivos como las herramientas que usábamos para hacer aplicaciones empresariales hace 20 años. Que sí, que sí, que Spring y Java EE son mucho mejores, más flexibles, más escalables y todo eso, pero un programador RPG, Visual Basic o 4GL acaba mucho antes una aplicación con la misma funcionalidad de gestión que uno Java.
Yo no digo que tengamos que volver atrás, digo que hay que avanzar de verdad.
Javier, desde mi punto de vista un motivo para cambiar si ambos ofrecen lo mismo es que Java EE es un estándar sin lockin, mientras que Spring, por más opensource que sea, es un producto de una empresa.
No estoy seguro de optar, en forma exclusiva, por una de las alternativas (Spring o JavaEE) pero he visto varios productos open source (no me refiero a una aplicación x en una empresa sino productos que se usan en multiples empresas) que utilizan spring en su desarrollo, en ese sentido en lo personal un indicador para tomar una decisión sobre la pregunta será observar si estos productos se animan o no a dejar de usar spring y optar por JavaEE.
Saludos,
spring = xml para todo lo útil y también lo inútil ya se que puedes reducirlo pero los desarrolladores y igual lo agregan aunque crees con casi nada de xml entonces igual jee6 con lo mínimo de xml tiene menos xml que spring con lo mínimo de xml
Configuración típica de jee6 persistence.xml que lo tiene spring también un beans xml con una sola linea de menos de 10 caracteres no web xml y la vista en xml (lo cual puedes reducirlo con metawitget o cualquier otro framework de vista) spring casi lo mismo solo que con el doble de xml
Un servicio de jee6 clase sin interface (refactorisas y las sacas si la necesitas) menos de 5 anotaciones y nada de xml y usa composición para la persistencia llamando al entitymanager directamente y de regalo en la misma clase le pones las anotaciones de rest
Transacciones jee6 todo funciona con configuración por defecto y casi nunca necesitas cambiarla
Librerías para jee6 las de reportes y testing y resto las tiene el servidor opcional algún framework para la vista
Para spring más de 20 jars que llaman a otros jars que nadie sabe para qué sirve
Tiempo de carga del servidor si realmente sabes lo que haces no lo levantas casi nunca y pruebas todo con pruebas unitarias usando el patrón mvp en caso de levantarla unos segundos con glasfish y cambios en caliente asta en los servlets
Para los aspectos en jee6 clases anotadas sin xml sin ninguna interface para spring te armas la de los 1000 demonios agregando aspectj y para la injecion de dependencia cdi
Persistencia con jpa en spring usas el framework para usar el framework de persistencia de jpa(si es absurdo) si quieres usar tapersty pues lo usas pero par spring usas el framework para usar el framework tapersty(si parece patológico)
Si existen los biding y usan un enfoque mas pragmático que spring no usan un controller que agrega horriblemente a un map (no type safe) ni tanpoco necesitas un xml gigantesco donde describes todo lo que se puede describir hasta el detalle más insignificante de la aplicación
Los ejb no son pesados estamos en el siglo 21 en el año 2011 para los despistados cuando piensas en que es pesado estas pensando en las primeras versiones de ejb las últimas versiones requieren menos configuración que las primeras dejen de quejarse y comparar spring con la primera versión de ejb que spring es mejor porque no necesitas ejb la ultima versión de ejb requiere menos configuración que nunca incluso menos que spring
cuando veo spring programo mas en el xml (sin ayuda del compilador) gracias a la ideosincracia de "no configurado aqui" cuando hago refactoring destruyo la aplicación por que no esta actualizada con su xml cuando hablo de arquitectura me responden en 3 capas o mas pero lo único que hacen es triplicar o cuatruplicar las clases y hacer lo mismo creando métodos de una línea que llaman a otra clase que llaman a otra así como 5 o 6 veces asiendo al final lo mismo cuando hablo de patrones y poliformismo me responden que tienen clases que usan el patrón service serviceimple para todas las clases cuando les hablo de modularidad me hablan de capas pero igual por alguna parte se les escapa una importación entre paquetes de forma circular
cuando hablo de diseño me responden que descargaron los plugin para hace interfaces de usuario y que usan dreanweaber wtf cuando les pregunto por qué usan 3 capas o más me responden porque es "buena práctica" pero qué utilidad tiene desacoplar una aplicación de si misma cuando tu eres dueño del código fuente todo lo estás haciendo en un solo servidor cuando les hablo de refactoring me responden que no estoy siguiendo la arquitectura que estoy cambiando el estándar que nadie entiende los patrones wtf cuando les ablo de programación me hablan en términos de gui "jalo la tabla de la paleta y le pongo next 5 veces" y por supuesto todo tienen que funcionar configurando e instalando cientos de plugins y programas para aumentar la productividad para “agilizar” el uso de sus frameworks wtf
Conclusión spring va a matar a java con ayuda de los desarrolladores y arquitectos y además spring es la versión del siglo 21 ejb v1
lo mas gracioso de todos es que existen religiosos de ambos la dos del dogma que predican migración unos de jee a spring y otros de spring a jee y luego a los desarrolla dores la mitad por dentro esta maldiciendo la decisión de la migración y la otra mitad esta feliz XD total decídanse de donde a donde se migra y cual es el menos malo XD
Aunque esté de acuerdo en que la productividad podría ser bastante mejor, estas comparativas siempre son algo tramposas. Las aplicaciones empresariales de hace 20 años no se accedían desde cualquier parte del mundo sin instalación previa y desde casi cualquier dispotivo sin tocar nada, así que compararlas con las aplicaciones de ahora no tiene sentido.
Es como decir que los moviles son una patata por que los teléfonos de hace 20 años no tenían problemas de cobertura ni se quedaban sin batería a las pocas horas de uso.
El problema está, pero la cosa no va por ahí ;).
Eso de la inyección JEE6 se puede usar en aplicaciones escritorio? Parece que no
Hay algo parecido a spring web flow en JEE6? Parece que no
Cuántos de vosotros usáis servidores JEE6 en producción? Porque me da la sensación de que los proyectos que están en mantenimiento/evolutivos no van a migrar de servidor de aplicaciones sólo para usar las nuevas características de JEE6. En cambio, sí que es factible añadir a un mantenimiento o un evolutivo un nuevo módulo de tu aplicación que use Spring. Dicho de otro modo, JEE6 funciona en servidores J2EE 1.4 o JEE5 (es una pregunta retórica)? porque Spring sí que lo hace.
Soporte para la nube? Spring -> Cloud Foundry (no estoy seguro, pero creo que es de pago); JEE ->...
Algo similar a Spring Batch? y Spring ROO? Yo quiero hacer aplicaciones rápido, lo de "empresarial" es una palabra algo vacía (es decir, Spring, sin ser "empresarial" te provee de las mismas características "empresariales").
Spring es un producto de una empresa, pero es FOSS. Seguir los estándares porque son los estándares y por tanto sin "vendor lock in" no es cierto. Hablamos de los estándares de la plataforma JEE, que es un producto FOSS, de otra empresa, Oracle, que cuándo quiere también tiene sus puñetitas con la competencia (Android, coff coff, Harmony coff coff).
Del otro lado, Spring fue pensado para que sea posible hacer una aplicación Spring sin dependencias con Spring en el código, facilitando su sustitución por otro framework de inyección de dependencias (Guice o el mismo JEE).
Por otra parte, habría quien entienda que el hecho de no definir unos estándares (estilo JCP), hace que su desarrollo sea mucho más rápido y se adapte a las necesidades de *sus* usuarios mucho antes. No lo suscribo al 100%, pero creo que tiene su puntillo.
Por último, y no por ello menos importante: ¿ofrece JEE6 algo sustancialmente mejor que Spring? El éxito de Spring ha radicado en que era un paso de gigante respecto a las aplicaciones empresariales de entonces. Y le lleva creo que 10 años a JEE6. Es decir, que ha establecido unas prácticas y unos modelos de programación que pueden entenderse como estándares "de facto".
Finalizando, creo que Spring tiene bastante más "momentum" que JEE6 y soluciona problemas/simplifica desarrollo en otros ámbitos además del empresarial (escritorio, batch), y teniendo más alcance en el ámbito empresarial (nube, web flow). Por otro lado JEE6 no añade nada sustancialmente mejor que lo ya existente (no sólo Spring, sino también Guice), es decir, no va a hacer que mi aplicación sea *mucho* más sencilla de programar (tanto, que hoy por hoy me justifique el cambio) ni que los tiempos de desarrollo sean mucho menores.
¿Es un buen momento para cambiar a JEE? Yo creo que Spring aún tiene mucha inercia y una base de usuarios/desarrolladores mucho mayor que JEE6. ¿Qué nos deparará el futuro? No lo sé, si lo supiera no estaría aquí soltando este chorizaco, estaría comprando los décimos ganadores de la lotería de Navidad :O)
saludos y paz a todos, hamijos de retrospecter!
Hola, me agrada ver por aquí gente que sigue apoyando Spring, lo digo porque también me encuentro con artículos sobre abandonarlo y me entristece porque ahora me he animado en serio a aprender este framework, aunque me está costando bastante, más de lo que sugieren las curvas de aprendizaje, tengo un libro, guías, step-by-steps, getting stated, internet y por supuesto stackoverflow, pero aún me sigue costando asimilar la innumerable cantidad de piezas que compone un proyecto hecho por ejemplo con Spring. Soy de Almería, aquí no hay trainings como tantos que hay en Madrid y mis compañeros -generalizando-, realmente, casi no saben que existe más allá de Java, ni les interesa. Dicho todo esto, aún viendo estos artículos me he decidido a aprender Spring y allá que voy aunque echo en falta medios de comunicación directos, más informales y concretos como era antiguamente el chat... Si hoy en día hay algún canal en IRC sobre Spring, etc me encantaría conocerlo porque me surgen miles de dudas que buscarlas en internet es difícil y costoso y son demasiado tontas como para preguntarlas en stackoverflow -por poner un ejemplo-... Me refiero al tipo de "No me arranca el servidor Tomcat y no entiendo que pasa ahí abajo como para plantear la duda en un foro" o "cómo convertir un proyecto maven a un Spring MVC, qué tengo que sustituir, qué dejar..."
Mi pregunta es cómo se desenvuelven ustedes en el aprendizaje de Spring, qué leen, a quién acuden, canales aquí en España (si los hay), etc
Muchas gracias..
Spring ofrece clases de soporte para el testeo y que yo sepa JEE6 no. Sólo para el testeo ya vale la pena Spring.
lluis, muchas gracias por compartir tu opinión pero, en mi modesta opinión, tu post es ininteligible. Te agradecería enormemente que prestases algo de atención a la redacción para que todos podamos disfrutar de tus conocimientos.
Un saludo!
Con J2EE el desarrollo es mas simple, no necesitas tocar muchos xmls como si lo tienes que hacer en Spring, todo es mas simple en J2EE @WebServlet @WebService @Entity etc.
Hombre en la capa de presentación tienes JSF 2.O que es un standar y tiene multitud de librerías de componentes que te hacen ganar mucho tiempo de desarrollo (Richfaces de JBoss, Icefaces, PrimeFaces, Myfaces Tomahaw de Apache y muchas otras) . Hay dos implementaciones de JSF, una de Oracle y otra Apache. Yo la utilicé hace tiempo y quede contento. Eso sí, tiene una curva de aprendizaje mas lenta. Al que le guste Spring MVC, puede seguir utilizándolo y emplear JSF únicamente como capa de presentación, aunque JSF de por si es un framework MVC.
Pues yo estoy con Javier Paniza. No se ha avanzado nada. Y no solo lo comparo con VB, si no simplemente con los servlets.
Yo he vivido (no como programador, desde fuera) una migracion de un portal hecho con servlets a otro que hace lo mismo (bueno, los jpgs son distintos) con Spring+Hibernate+todolohabitual (menos NoSQL creo que no falta nada) y el resultado ha sido descorazonador. Antes los programadores practicamente se tocaban las narices la mitad del tiempo, los proyectos acababan antes (y en fecha), se subian sin problemas, los cambios en un sitio no afectaban a los demas y funcionaban bien en produccion. Ahora hay mas gente tirando lineas, curran mas, subir las cosas a produccion es un circo, se toca en un sitio y se afecta a otro y hay mas incidencias.
Es un portal normal y corriente, de esos de contratar servicios, sin mucha carga, pero joder.... Y la culpa no debe ser de no saber usar Spring, porque lo diseñaron dos arquitectos que lo llevaban usando bastante tiempo y lo habran seguido usando desde entonces.
No se J2EE, pero desde luego Spring ha sido una decepcion. Los desarrolladores estan contentos porque tienen el curriculum lleno de siglas, pero no hay color con como funcionaba el portal con servlets. Y eso que tampoco es que lo viejo no fuera codigo espaghetti, que tambien habia que verlo....
Hola Verdoso,
Sí tienes razón, de hecho ese mismo razonamiento casi con las misma palabras lo he esgrimido mil veces. Pero cuando trabajas en una empresa donde se usan otras tecnologías de desarrollo más tradicionales no todo el mundo puede entender la falta de productividad de Java.
Eso me recuerda lo que dijo Stroustrup (creo): "Dicen que algún día será más fácil usar un ordenador que un teléfono, ese día ya ha llegado, yo no sé usar mi teléfono" o algo así.
Hola Abraham,
El problema es que migrar de Spring a Java EE una aplicación no trivial es algo muy costoso y al final el valor real que añades a la aplicación no es perceptible por el usuario. En ese tiempo que tú te dedicas a migrar tu competencia hará que su producto sea más rápido, más bonito y tenga más funcionalidad y tú perderás.
Realmente Spring funciona en cualquier servidor JavaEE. Y en lo del "lockin" tienes razón pero el "lockin" forma parte de nuestra vida o si no desintala el Windows, tira tu iPad y tu Mac, deja de usar Eclipse, Ant, Maven, jUnit e Hibernate. Ni siquiera podrías usar linux. Al final la mayor parte de las cosas que usamos no son estándares. ¿Y cuantos estándares han fracasado? ¿Que me dices de XHTML o CORBA?
Tenemos que centrarnos en hacer aplicaciones que hagan que al usario se le caiga la baba... todo lo demás no importa
Sí, yo también he tenido que aguantar eso de "¡¡Pero como tardais tanto en hacer eso, si con Accés yo te lo hago en dos horas!!". Es lo que hay :). Todavía la cosa del "tempo Internet" anda entre la inmadurez y la incomprensión. Así le va a la gente con las previsiones.
Mi telefono es un dumbphone y no uso ni el 20% de lo que tiene...
si es que en java los que no saben no saben nada y los que saben se la quieren hacer de mega arquitectos creando inmensas y complicadas arquitecturas en conclusión tenemos a un mega arquitecto con su obra maestra en papel y varios que tratan de imitarlo siguiendo religiosamente todas sus recomendaciones aunque sean excesivas
los de otros lenguajes simplemente usan lo que tienen que resuelven problemas de forma fácil con soluciones simples no les interesa cosas como patrones arquitectura desacoplamiento etc ellos simplemente abren su acces crean una consulta copian y pegan la misma consulta en el código jalan una grilla y pegan el código que les falta y repiten la mismo todas las veces que lo necesiten pero para los de java eso es sacrilegio nosotros creamos una clase de dominio luego creamos un dao luego creamos el mapeo luego hacemos la prueba unitaria luego creamos un montón de interfaces para luego hacer que una clase llame a otra clase que llama a otra clase (todo con métodos que no hacen nada de una sola línea)
Hay algo parecido a spring web flow en JEE6? Parece que no
-hay un montón de frameworks de vista libres mejores que la de spring
-existen un montón de implementaciones de jsf
-que de especial tiene que todo dependa de cadenas ósea te parece bien que tu formulario de loguin devuelva una cadena que diga acepta o denega y luego creas un archivo xml donde repites lo mismo el formulario loguin devuelve acepta que va al formulario acepta y luego el formulario loguin devuelve denega que va al formulario denega así para las 50 formularios que tienes
Spring ROO?
En serio el código auto generado es una peste violan todas reglas que se puedan violar además spring roo va rápido hasta que te das cuenta que solo hace cruds y que no es más que la evolución del copy and paste
Hacer refactoring con ayuda del compilador y el ide sin destruir la aplicación por que el xml y las clases java no están en sincronía me parece motivo de sobra, que casi todo tenga configuración por defecto y anotaciones es mejor que casi todo tenga que tener xml y si es mas fácil de programar sin xml para todo
Eso si reconozco que java no ofrece nada bueno en la parte que no sea “empresarial” el escritorio siempre fue maltratado y olvidado
Hola a todos.
En mi humilde opinion veo dos aspectos:
1.- Si ya tenemos una aplicación desarrollada en Spring con todas sus ventajas y desventajas, no tiene mucho sentido migrarla a JEE6 solo porque este ya creció y ofrece casi lo mismo , lo mismo u algo mejor.
2.- Si se planea desarrollar una nueva solución, ahi cambia la cosa. Si tengo el standard que me ofrece un 95% y tengo otro producto que me ofrece un 90% ± 10%
no veo la necesidad de usar Spring, no veo la necesidad de configurar mas y mas.
Ahora por lo de "Productividad de java" yo también pase por " una semana?? si eso yo lo hago en un día usando VB!!!"
Ahora la solución no es quedarse llorando y esperando a que algún grupo de desarrolladores innovadores creen un framework que nos haga la vida mas fácil. La solución es usar el cerebro, usar la creatividad ( estudio ingeniería y amo el Javaaaa ) asi como con el producto de Javier Paniza.
Cuando mi jefe me dijo lo de "yo lo hago en un día" me quede picon. No dormi como 3 días y al final hice mi mini_framework que me auto generaba en 5 minutos todos los *.java, *xhtml necesarios para el mantenimiento de una tabla ( usando icefaces,hibernate) es decir eliminar, listar , editar y crear.
Aunque cada proyecto es diferente y requiere de planteamientos diferentes, me quedo con Spring. Me confieso afectado por aquella peste negra del ejb 2.0 que hubo en su día y que nos hizo huir a tantos del estandard JEE pero los argumentos para mí siguen siendo los mismos que entonces.
- El runtime que requiere el núcleo es la propia jvm, punto pelota, en lugar de un servidor JEE que suele ser pesado y con frecuentes problemas de portabilidad, aunque la especificación diga lo contrario (trata de correr un ear de JBoss en otro de GlassFish, por ejemplo).
- Tiene un stack de servicios adicionales que te cubren muchas, muchas necesidades.
Just my 2 cents,
1- Yo vengo a ser un caso muy distinto a los que le "tiran" a Spring. Soy un tipo al que los xml no le molestan en lo absoluto, de hecho creo que me facilitan la vida, y una vez que dominé el núcleo del framework, los desarrollos han sido "coser y cantar", el mantenimiento una pasada y las integraciones unas vacaciones. Ya les digo seré un caso poco frecuente, y debo admitir que me costó entenderlo todo, la suerte fue que empecé cuando estudiante :). Discrepo de aquello que se dice de que con Spring no se es productivo, de hecho los atrasos que he sufrido en mis proyectos nunca tuvieron como motivo algo relacionado al framework.
2- @luis no veo lo absurdo en "con jpa en spring usas el framework para usar el framework de persistencia de jpa". Yo le veo como algo inteligente, te ofrezco una integración con las funcionalidades más comunes de los framworks de persistencia (o lo que sea) más utilizados. ¿Qué hay que absurdo en eso? Como mismo rezan sus dichos, ¿para qué re-inventar la rueda, mejor te pongo a disposición herramientas de como usarla? Siendo Spring un framework de inversión de control, lo absurdo sería inventar un framework de persistencia que no tenga nada nuevo cuando hay mínimo 3 o 4 que ya lo tienen todo. "cuando hablo de arquitectura me responden en 3 capas o mas pero lo único que hacen es triplicar o cuatruplicar las clases" ya eso depende que estés desarrollando y cómo, lo veo como un problema particular, tu puedes establecer cuantas capas quieras, como si en los DAOs quieres establecer todo el negocio y lo sgte sean las vistas, es a gusto del consumidor. Yo (aclaro de nuevo un chico en contra del mundo) veo muy limpio el programar orientado a interfaces como me "educa" el framework, incluso con el patrón hollywood (no sé si así se llama, es como le conozco) me evito los dolores de cabezas de las migraciones, mañana quiero dejar de utlizar el framework y me resulta sencillo (no me ha pasado pero por curiosidad lo he probado, sé que no es lo mismo pero bue...). "pero igual por alguna parte se les escapa una importación entre paquetes de forma circular" Bueeeeeno ya eso no tiene que ver con el framework, chequea con tus arquitectos (los míos me dan un dolor de cabeza terrible también) que tendrán que estudiar un poquito más, sin ánimo de ofender ni de ser pedante ¿vale? ;). "Conclusión spring va a matar a java con ayuda de los desarrolladores y arquitectos y además spring es la versión del siglo 21 ejb v1" Una opinión y como todas respetable, no coincido, que tus arquitectos y desarrolladores no utilicen bien una herramienta no significa que vayan a matar a la plataforma. Spring es considerado hoy por hoy como un estándar de facto, más allá de estar de acuerdo o no con eso créeme, este reconocimiento no se logra haciéndole la vida imposible a las personas.
3- @nilojg no me dices nada cuando afirmas "...la culpa no debe ser de no saber usar Spring, porque lo diseñaron dos arquitectos que lo llevaban usando bastante tiempo", pueden llevar 500 años trabajando con Spring, si de conceptos base no andan sobrados no puedes esperar mucho, ¿no crees? Ese proble que antecede la cita que traje a colación lo veo como una experiencia dolorosa, te digo lo mismo que a luis, hay que ver como utlizaron el framework y para qué, quizás no lo utilizaron de forma correcta o para lo que lo utlizaron era mejor lo que ya tenían, y porque a alguien se le ocurrió que el framework "estaba a la moda" había que migrar porque sí, quién sabe. "Y eso que tampoco es que lo viejo no fuera codigo espaghetti, que tambien habia que verlo...." ves ya podemos diculicdar algunas cosas, en fin que no digo que Spring sea el cielo y lo demás el infierno, sólo que algunas cosas que le imputan son falsas, y con otras simplemente no estoy de acuerdo.
4- Vaya @juan con eso de "Tiene un stack de servicios adicionales que te cubren muchas, muchas necesidades. " ahi le has dado !!!
Saludos a todos.
Perdón, pero a mi me interesa la métrica de actividad del proyecto, si tengo más actividad tengo más código y tengo probablemente más bugs. Eso no significa que sea peor. Prefiero tener nuevas características a estancarme en lo que ya existe. El alma de Jenkins es, fue y va a seguir siendo Kohsuke. Esta es una clara muestra del poder del Open Source. Oracle me desilusionó totalmente al pelear por el nombre de Hudson, me pareció un enfoque totalmente infantil.