En desarrollo Liferay, el IDE no es solo un editor de texto glorificado. Es la herramienta donde pasas la mayor parte del dia: navegando entre modulos OSGi, editando archivos service.xml, desplegando portlets, depurando servicios y gestionando configuraciones de Gradle. La eleccion del IDE impacta directamente en tu productividad y en la friccion diaria del desarrollo.
He trabajado con ambos IDEs extensivamente en proyectos enterprise con Liferay DXP desde la version 7.1 hasta la 7.4. Esta comparativa no es teorica: esta basada en problemas reales, workarounds que tuve que aplicar y las razones por las que hoy uso uno como herramienta principal y el otro como complemento.
Liferay Developer Studio (LDS) es la distribucion oficial de Eclipse que Liferay ofrece como parte de su suscripcion enterprise. Viene preconfigurado con plugins especificos para desarrollo en la plataforma.
La mayor fortaleza de LDS es que todo funciona out-of-the-box para Liferay. No hay configuracion inicial: creas un Liferay Workspace, agregas modulos con los wizards, haces deploy con un click, y el debug attach se configura automaticamente.
El editor de service.xml es genuinamente util. Cuando trabajas en un proyecto con decenas de entidades y cientos de columnas, la vista tabular con validacion en tiempo real ahorra errores. He visto proyectos donde un error de tipeo en service.xml causo horas de debugging; el editor visual previene esa clase de problemas.
La consola Gogo Shell integrada es otra funcionalidad que uso frecuentemente. Poder ejecutar lb | grep mi-modulo para verificar que un bundle se desplego correctamente sin cambiar de ventana es un micro-ahorro que se acumula.
Eclipse, la base de LDS, muestra su edad. El indexado de proyectos grandes es notablemente mas lento que en IntelliJ. En un workspace con mas de 30 modulos, he experimentado tiempos de indexado inicial de 15 a 20 minutos, durante los cuales el IDE es practicamente inutilizable.
El manejo de memoria es otro punto debil. Con proyectos enterprise, LDS frecuentemente requiere aumentar el heap de la JVM a 2 GB o mas, y aun asi puede volverse lento despues de varias horas de uso continuo. El clasico "reinicia Eclipse" es un ritual que todo desarrollador Liferay conoce.
El soporte de Git integrado en Eclipse (EGit) funciona, pero es tosco comparado con alternativas modernas. Operaciones como rebase interactivo, cherry-pick selectivo y resolucion de conflictos son mas engorrosas que en IntelliJ o incluso que usar Git desde la terminal.
IntelliJ IDEA no fue disenado para Liferay, pero su calidad como IDE Java general y la existencia del plugin de Liferay lo convierten en una alternativa seria.
JetBrains y la comunidad mantienen un plugin de Liferay para IntelliJ que ofrece:
service.xmlEl plugin no es tan completo como LDS, pero cubre los flujos de trabajo principales.
Rendimiento: esta es la diferencia mas inmediata. IntelliJ indexa el mismo workspace de 30+ modulos en una fraccion del tiempo que LDS. La navegacion entre clases, la busqueda de referencias y el autocompletado son consistentemente mas rapidos.
Refactoring: las herramientas de refactoring de IntelliJ son superiores. Renombrar un servicio OSGi y que el IDE actualice automaticamente todas las anotaciones @Reference, los archivos de configuracion y las declaraciones de componente es invaluable en proyectos grandes.
Integracion Git: IntelliJ tiene la mejor integracion Git de cualquier IDE que he usado. El visor de diff, la herramienta de merge, el log interactivo y la capacidad de hacer commits parciales (chunks) hacen que la gestion de version control sea fluida.
Soporte Gradle: ambos IDEs soportan Gradle, pero IntelliJ lo maneja mejor. La sincronizacion de proyectos Gradle es mas fiable, los errores de configuracion se reportan con mas claridad, y la ejecucion de tareas Gradle desde el IDE es mas rapida.
Ecosistema de plugins: mas alla de Liferay, IntelliJ tiene plugins para practicamente todo: Lombok, Docker, bases de datos, REST clients, Kubernetes. En proyectos donde Liferay es solo parte del stack, este ecosistema es valioso.
La ausencia del editor visual de service.xml es la perdida mas notable. Editas XML puro, y aunque IntelliJ ofrece validacion contra el DTD, no tienes la vista tabular que LDS proporciona. Para proyectos con modelos de datos complejos, esto es una desventaja real.
No hay consola Gogo Shell integrada. Necesitas conectarte al Gogo Shell via telnet manualmente o usar una terminal dentro del IDE. Es un paso extra que interrumpe el flujo.
La edicion Community de IntelliJ es gratuita pero carece de soporte para Java EE, Spring y otras tecnologias enterprise. Para desarrollo Liferay serio, necesitas IntelliJ Ultimate (de pago) o aceptar algunas limitaciones.
Blade CLI es la herramienta de linea de comandos oficial de Liferay para crear proyectos y modulos. Funciona independientemente del IDE, lo cual es su gran virtud.
# Crear un nuevo Liferay Workspace
blade init mi-workspace -v 7.4
# Crear un modulo de servicio
blade create -t service-builder -p com.ejemplo -c Solicitud solicitud
# Desplegar un modulo
blade deploy
# Iniciar Gogo Shell
blade sh lb
Blade CLI genera la misma estructura de proyecto que ambos IDEs reconocen. Esto significa que puedes crear un proyecto con Blade, abrirlo en IntelliJ para desarrollo diario, y ocasionalmente abrirlo en LDS cuando necesites el editor visual de service.xml.
Despues de anos trabajando con ambos entornos, esta es mi configuracion actual:
IntelliJ IDEA Ultimate como IDE principal. Lo uso para el 90% del trabajo diario: escribir codigo, navegar el codebase, debuggear, gestionar Git, ejecutar tareas Gradle, desplegar modulos. La velocidad y las herramientas de refactoring compensan la falta de integracion nativa con Liferay.
LDS como herramienta complementaria. Lo abro cuando necesito el editor visual de service.xml para modelos de datos complejos, cuando quiero usar los wizards para crear un tipo de modulo que no conozco bien, o cuando necesito Gogo Shell integrado para una sesion de debugging intensiva.
Si decides adoptar IntelliJ como IDE principal, estos son los pasos de configuracion esenciales:
1. Instalar el plugin de Liferay: disponible en el marketplace de JetBrains. Reinicia el IDE despues de instalarlo.
2. Importar el Workspace como proyecto Gradle: abre la carpeta raiz del Liferay Workspace. IntelliJ detectara el settings.gradle y cargara todos los modulos automaticamente.
3. Configurar el JDK: Liferay 7.4 requiere JDK 11. Asegurate de tener un JDK 11 configurado como SDK del proyecto en File > Project Structure > Project > SDK.
4. Configurar el servidor Liferay: en Run > Edit Configurations, agrega una configuracion de servidor Liferay apuntando a tu bundle local. El plugin de Liferay para IntelliJ deberia ofrecer esta opcion.
5. Optimizar la memoria: para workspaces grandes, edita el archivo idea64.vmoptions y aumenta el heap:
-Xms512m
-Xmx2048m
-XX:ReservedCodeCacheSize=512m
6. Excluir directorios del indexado: en File > Project Structure > Modules, marca como excluded los directorios build/, bundles/, y .gradle/ de cada modulo. Esto acelera dramaticamente el indexado.
7. Configurar Gradle: en Settings > Build, Execution, Deployment > Build Tools > Gradle, selecciona "Build and run using: Gradle" y "Run tests using: Gradle". Esto asegura que el comportamiento de build en el IDE sea identico al de la linea de comandos.
La eleccion del IDE es personal y depende del contexto del proyecto. Lo importante es conocer las fortalezas de cada uno y no limitarte a usar solo una herramienta cuando la combinacion de ambas te da la mayor cobertura.