que criterios tomar para sabe el nivel de madurez de un frameworks para aplicaciones web en java

Estimada comunidad, quisiera hacerles una pregunta. ¿Cómo medir el nivel de madurez que tiene una framework?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

uff

Difícil pregunta. Para empezar, ¿qué entiendes por "madurez" en un framework o cualquier otro software?

Puedo comentar acerca de una experiencia que tuve el año pasado para decidir algo como lo que mencionas:

Tenemos en mi chamba varias aplicaciones hechas en Tapestry 3, desarrolladas en 2004-2007. Empezamos con Tapestry 3 porque era lo más decente que había en ese momento, le daba vueltas a Struts y pues JSF apenas empezaba y también se veía bastante austero en comparación. Pero nunca hicimos actualización a Tapestry 4 porque había muchas incompatibilidades con la 3. Y luego salió la 5 que fue una versión reescrita desde cero (y que por tanto yo creo que deberían haberle puesto otro nombre; si no, es como "guns n' roses" cuando ya nomás es Axl y unos hueseros) y obviamente era incompatible con la 3 y la 4.

Así que cuando llegó el momento de actualizar las aplicaciones, nos dimos cuenta que estábamos arrinconados; para actualizar a Tapestry 5 había que reescribir buena parte de las aplicaciones. Y yo estaba ya muy molesto con esta actitud del autor de Tapestry de que cada versión es incompatible con la anterior; aunque ahora prometía mantener la compatibilidad hacia atrás, yo decidí que sería mejor buscar otra opción.

Evaluamos Vaadin, Grails, y algo que terminaba en Faces. Vaadin se veía bien pero tenía algunos problemas de performance con muchos usuarios concurrentes y había que estar haciendo algunos malabares para desplegar objetos de Hibernate o donde fuera, en sus componentes visuales. Y como que no encontré una comunidad en línea en dónde hacer preguntas, aunque no era un problema muy grande ya que su documentación es bastante buena y completa.

Lo del Faces (que finalmente es una implementación de JSF) nomás no. Muy rústico para mi gusto, era dar un paso atrás incluso de Tapestry 3, y la idea era irnos a algo más dinámico.

Y pues Grails al final es lo que me convenció. Las razones: tiene una arquitectura relativamente simple, su filosofía de convención sobre configuración es algo que ya conocía desde Tapestry 3, hay una infinidad de plugins para todo lo que se te ocurra, tiene una comunidad (o varias) bastante activa, excelente documentación, hay libros para ahondar más, se pueden tomar cursos en México, y por lo que estuve leyendo de las versiones, los devs de Grails tienen muy presente que es importante facilitarle a los usuarios la actualización de sus aplicaciones, de modo que están muy bien documentados los cambios que trae cada versión respecto de la anterior pero lo mejor es que puedes teclear "grails upgrade" en tu CLI y te actualiza tu app a la última versión (corre una serie de scripts de los plugins para actualizar dependencias y números de versión y cosas así; hasta donde yo sé no modifica código pero eso ya lo ves con la documentación).

Para mi la madurez se refleja en la comunidad de usuarios, en la estabilidad del framework (que se puede apreciar viendo qué tantos cambios hay de una versión a otra, y de qué magnitud son), en las tecnologías que hay debajo del cofre (o la falta de ellas; si hacen absolutamente todo desde cero podría ser un foco rojo), en el lenguaje que se utiliza... no sabría cómo medir esto de manera cuantitativa, pero pues al final la decisión fue migrar a Grails.

Mientras tanto, he visto que de Tapestry 5.0 a la 5.1 a la 5.2 a la 5.3 etc siempre hay que estar haciendo cambios y una aplicación hecha en una de esas versiones rara vez funciona con la siguiente versión sin tener que hacerle algunos cambios. Así que por muchas versiones que tenga ya, y que tiene ya mucho tiempo, no creo que sea un framework maduro.

Imagen de ezamudio

num.devs

El número de personas que están contribuyendo al proyecto es importante también.

Itegración

Algo que importa mucho es que tan bien puede convivir con el ambiente y que tanto permite al ambiente explotar su funcionalidad. Por ejemplo JUnit donde defines (en varias formas) que paquetes quieres capturar los eventos a registrar.

Imagen de ECI200

muchas gracias por apreciable

muchas gracias por apreciable su respuesta y si bien es cierto ...la competencia de los frameworks año tras año son reñidas ...confieso ser un novato en estas cosas ..de hecho hace poco he experimentado con Spring Roo y el código generado por ésta es en base a tecnologias usadas en el mercado ..como JPA, Hibernate que ha mi punto de vista es bueno y por ahi le sigue play framework... tambien con Struts 2 se diferencia mucho de Struts 1 caso parecido con las versiones deTapestry 5 y 4 que bien es cierto hay incompatibilidades y de hecho he experimentado con tapestry 5 su filosofia me encanta, sobre todos las anotaciones (IoC) ....ahora bien quisiera hacerle dos pregunta ..espero no molestarlo. ¿ por que JSF, (estoy confundido !!!) es una especificación que utiliza MyFaces o es un framework (disculpe la ignorancia)? y por que es utilizado mas JSF que Tapestry si éste ultimo fue el primero en estar orientado a componentes?

JSF es una especificacion

JSF es una especificacion J2EE originalmente de SUN y ahora de ORACLE, simplemente por eso es mas conocido y usado (ojo, no significa que sea mejor que otro, aunque la version 2.X ha mejorado mucho).