¿Es posible tener Liferay SDK en una ubicación diferente a la de los códigos fuente?

Question

Me gustaría preguntarle sobre las mejores prácticas para desarrollar con Liferay SDK. Tengo el SDK descargado, tengo Eclipse listo, funciona, puedo crear nuevos portlets y ejecutar la instancia local de Liferay para probarlo.

Aquí está mi situación: todo el código fuente que tengo está en el área de trabajo de Eclipse, actualmente son solo los portlets en los que estoy trabajando.

Liferay SDK Tengo en una ubicación completamente diferente que el espacio de trabajo. Digamos ~/dev/liferay_sdk. El espacio de trabajo de Eclipse está ubicado en ~/workspace.

Al principio, no funcionaba así. Eclipse por alguna razón no puede encontrar o usar Liferay SDK. Cuando cambié "Validación del proyecto" en la configuración de Eclipse/Liferay a "Ignorar" el "SDK de Liferay Plugin no es válido", comenzó a funcionar sin problemas.

El siguiente problema sucedió cuando se trata de construir un WAR por ejemplo. En el directorio del portlet en el espacio de trabajo está presente el archivo "build.xml". Pero dentro se refiere a otro archivo xml, que debe ubicarse un directorio arriba, y este se refiere a más cosas en relativamente ubicación, y así sucesivamente.

En resumen, se supone que tiene los portlets, etc., dentro del Liferay SDK. Me gusta "~/dev/liferay_sdk/portlets".

Mi pregunta es, ¿Me equivoco completamente, o podría sugerirme las mejores prácticas con esto?

No quiero mezclar SDK y el código, me suena mal.

¡Gracias por la ayuda!

Answer 1

Creo que la mejor práctica sigue siendo cuando los proyectos de su portlet se encuentran dentro del directorio SDK de Liferay Plugins.De esta forma, puede aprovechar todas las ventajas del complemento Liferay IDE para Eclipse, por ejemplo. Porque, según tengo entendido, Liferay IDE no le permitirá tener proyectos de portlet en otra ubicación. Es bastante fácil importar proyectos a Eclipse desde el directorio Liferay SDK, y eso no es problema.

Pero también me enfrenté al mismo tipo de problema cuando intenté guardar el proyecto de portlet en el repositorio de Git. Las posibles soluciones con enlaces simbólicos no funcionaron correctamente en todos los sistemas. Por lo tanto, modifiqué ligeramente el archivo build.xml para poder ejecutar tareas ant desde cualquier directorio. Para los portlets que era algo así:

<project name="your-portlet" basedir="." default="deploy"> 
    <property file="build.properties" /> 

    <property name="project.dir" value="${liferay.sdk.home}" /> 

    <import file="${project.dir}/build-common-plugin.xml" /> 
</project> 

en cuenta que se debe definir la propiedad "liferay.sdk.home" en build.properties y debe ser ruta de acceso al SDK de Liferay plugins.

En cuanto a otros tipos de complementos de Liferay (temas, ganchos, etc.) debe importar otro archivo de compilación para compilar ese tipo de complemento. Por ejemplo, para temas será:

<import file="${project.dir}/themes/build-common-theme.xml" /> 

Espero que te hagas una idea. :) Pero piénselo dos veces antes de hacer algo así.

Answer 2

plugins Liferay se desarrollan en el interior del SDK Liferay plugins, se llama SDK por una muy buena razón.

no encuentro nada malo con el plugins-SDK y el código atadas Togather, a continuación son algunas de las razones por qué:

Si ve el liferay repository of plugins en github, se encontraría todos los portlets de ejemplo y otros los complementos se almacenan en sus respectivas carpetas dentro de los complementos-SDK.

lo tanto, si se quiere desarrollar plugins Liferay (con o sin IDE), la mejor práctica (la única manera eficaz Creo) es tener los proyectos creados dentro de las respectivas carpetas de plugins SDK como los proyectos de portlet dentro portlets carpeta, enlace de proyecto dentro de la carpeta hooks etc.

Si ha utilizado Liferay IDE cuando se crea un proyecto de plugin (proyecto Liferay) en este IDE se especifica el SDK y el tiempo de ejecución del servidor y lo que hace es que crea el proyecto dentro de su Complementos SDK y copia el archivo .settings, .classpath & .project dentro del proyecto creado. No crea el proyecto dentro de su espacio de trabajo como eclipse normalmente lo hace para otros proyectos.

Espero haber logrado explicarlo claramente y esto era lo que querías.

Answer 3

ya estoy bastante contento con las otras respuestas, esto podría haber sido distribuido a través de comentarios en los que, sino una respuesta por separado da algunas opciones más estructurantes:

como dice Prakash, no es muy malo para hacer eso . Además de su respuesta, no necesita tener su código en el directorio del espacio de trabajo. Eclipse se complace en colocarlo en cualquier lugar del sistema de archivos, por lo tanto, mientras trabajas con Eclipse, ni siquiera importa dónde está exactamente tu código (y cuando lo registras en el control de versiones, ¿verdad?) En realidad nunca debes preocuparte.

Si desea utilizar los scripts OOTB ant de Liferay: están orientados exactamente a la configuración que describe: Trabaja en el directorio SDK. En realidad no está mal, pero si no te gusta, solo tienes que aceptar que puedes No funciona con build.xml sin cambiarlo (como sugiere Artem).

Otra opción es utilizar maven; esto también evita el sdk (y la integración de Liferay IDE), por lo que puede volver a poner su código fuente donde quiera y dejar que Maven haga el resto.

Puedo imaginar algunas cuestiones bastante esotéricas y raras con la sugerencia de Artem (como referirme a temas principales personalizados cuando implica una posición relativa) pero considero que son extremadamente menores, por lo que si eso funciona para usted: Adelante. Solo tenga en cuenta que no cumple con las suposiciones básicas que hace el SDK, por lo que podría tener que cambiar las cosas que violan las suposiciones. No puedo imaginar que esto sea demasiado difícil si lo tienes en cuenta.

Por supuesto, lo que extrañas con esa solución es el buen manejo de incluir build. $ {Username} .properties: tendrás que tener tus propias build.properties que definan $ {liferay.sdk.home}. Si no trabajas en un equipo, está bien. De lo contrario, tendrá que inventarlo usted mismo (y codificarlo) o depender de los parámetros globales que se configurarán con cada miembro del equipo.