I slowly worked away unguided at the setup and configuration of my plug-in projects and have now got as far as I think is possible with this version of Liferay IDE - v 1.5.3
My greatest fear is that Liferay IDE 1.6.0 will solve the problems I found work-arounds for in 1.5.3 and mean I wasted my time. But that is life, or maybe - that is liferay
I figured I would note down my findings for the benefit of anyone else who wants to use Liferay IDE but gets stuck on some of the issues that I got stuck on.
First up, this is deployed against Liferay Portal 6.0.6 but I don't think that makes a big difference compared to 6.1. The issues seem to be Eclipse and Liferay IDE-specific.
Also I'm using Eclipse Indigo on Java 1.6.0_30 and Ubuntu as my OS, and I'm using Maven M2E for dependency management and M2E-WTP for dynamic web projects v2.5
The liferay-portal installation was pain-free, although the 'clean-appserver' ant target was a bit of a surprise. Before using Liferay IDE, I was doing everything on the command line and my worst nightmare was deploying and re-deploying the ext-plugin. It involved hunting down and deleting or removing various files and lines of config in files. Liferay IDE's clean-appserver takes a bold approach - delete the whole liferay portal installation and unzip a fresh clean copy from the downloaded zip! The guys who wrote this stuff must have been listening to Metallica when they wrote that. In actual fact there isn't such a big problem with redeploying everything like themes or JDBC drivers or whatever - you can install that into a clean liferay portal and zip that up so it's there again after nuking it with clean-appserver.
When I installed Liferay IDE and configured it, there were a few little issues that arose. My predecessor had checked in the Liferay plugins sdk directory tree to Perforce source control, but something was wrong with it - Liferay IDE refused to recognise the liferay-plugins-sdk dir where my company's projects are. As a work-around, I just unzipped a fresh copy of the liferay-plugins-sdk-6.0.6 and then fetched my projects out of Perforce straight into it. After my investigations finally led me to download the source code for Liferay IDE, I checked for the error message and discovered these are the pre-requisites that a valid Liferay Plugins SDK has to have:
For some reason, what I have in Perforce no longer has a build.properties in the liferay-plugins-sdk root. Fortunately, it doesn't matter what the directory is called - later on I discovered the project directories have to be named with particular suffixes to be imported. Since I have no idea what else was changed in my liferay-plugins-sdk directory before I took it on, I decided the best approach is to copy my whole directory tree over the top of the freshly unzipped download.
There's another thread on this forum here - Thoughts on getting started with Liferay IDE - where the original poster criticises the necessity to build our liferay extensions within the liferay plugins sdk directory itself - which is a bit like modifying the tool you are using while you work with it. I totally agree - and it looks like Liferay IDE is going to fix the issue, so that's another plus point to look forward to.
My first experience with Liferay IDE was with theme projects. My firm has about 20 theme projects and it's just CSS, so it was a good simple point to start. They all just imported nicely into Eclipse, installed simply onto the Liferay server in Eclipse and let me work on the CSS as if I was editing the copy on tomcat itself. I'm not sure I wasn't actually but I think Liferay IDE actually copies the files over when they are saved.
The hook and layout projects installed well too.
However I couldn't import some projects because imports are restricted to projects that follow an undeclared naming convention:
I had to import my incorrectly-named extension project as a normal project and then set it up manually as a liferay project to achieve the same effect.
I also have a project in the liferay-plugins-sdk/webs directory - this was the only reference I could find to the webs directory - Hooks and plugins Ext in Liferay which says it's for "regular Java EE web modules". To make this one work, I imported it as a general project and pretended that it was a hook project - I've no idea what the ramifications of that are and so far I haven't had to do anything but deploy the project, and that works alright.
Once I had all my projects set up, I tried deploying them and running liferay. Liferay IDE 1.5.3's handling of ext plug-ins seems to have a bug which means that other plug-ins that depend on it and have an entry in their liferay-plugin-extension.properties's required-deployment-contexts will not deploy because they cannot see that ext is deployed. So I had to ensure that no projects (mostly hooks) had the reference in docroot/WEB-INF/liferay-plugin-extension.properties to the ext plugin or they would not deploy.
I figure the required-deployment-contexts config is set up for the mechanical builds and deploys that we do, but as it is this work-around (deleting the property) is OK for now.
So that's that.
HTH
Regards
Adam
My greatest fear is that Liferay IDE 1.6.0 will solve the problems I found work-arounds for in 1.5.3 and mean I wasted my time. But that is life, or maybe - that is liferay
I figured I would note down my findings for the benefit of anyone else who wants to use Liferay IDE but gets stuck on some of the issues that I got stuck on.
First up, this is deployed against Liferay Portal 6.0.6 but I don't think that makes a big difference compared to 6.1. The issues seem to be Eclipse and Liferay IDE-specific.
Also I'm using Eclipse Indigo on Java 1.6.0_30 and Ubuntu as my OS, and I'm using Maven M2E for dependency management and M2E-WTP for dynamic web projects v2.5
The liferay-portal installation was pain-free, although the 'clean-appserver' ant target was a bit of a surprise. Before using Liferay IDE, I was doing everything on the command line and my worst nightmare was deploying and re-deploying the ext-plugin. It involved hunting down and deleting or removing various files and lines of config in files. Liferay IDE's clean-appserver takes a bold approach - delete the whole liferay portal installation and unzip a fresh clean copy from the downloaded zip! The guys who wrote this stuff must have been listening to Metallica when they wrote that. In actual fact there isn't such a big problem with redeploying everything like themes or JDBC drivers or whatever - you can install that into a clean liferay portal and zip that up so it's there again after nuking it with clean-appserver.
When I installed Liferay IDE and configured it, there were a few little issues that arose. My predecessor had checked in the Liferay plugins sdk directory tree to Perforce source control, but something was wrong with it - Liferay IDE refused to recognise the liferay-plugins-sdk dir where my company's projects are. As a work-around, I just unzipped a fresh copy of the liferay-plugins-sdk-6.0.6 and then fetched my projects out of Perforce straight into it. After my investigations finally led me to download the source code for Liferay IDE, I checked for the error message and discovered these are the pre-requisites that a valid Liferay Plugins SDK has to have:
- build.properties in root directory containing the line "lp.version=6.0.6"
- liferay-plugins-sdk/portlet/build.xml file
- liferay-plugins-sdk/hooks/build.xml
- liferay-plugins-sdk/ext/build.xml
For some reason, what I have in Perforce no longer has a build.properties in the liferay-plugins-sdk root. Fortunately, it doesn't matter what the directory is called - later on I discovered the project directories have to be named with particular suffixes to be imported. Since I have no idea what else was changed in my liferay-plugins-sdk directory before I took it on, I decided the best approach is to copy my whole directory tree over the top of the freshly unzipped download.
There's another thread on this forum here - Thoughts on getting started with Liferay IDE - where the original poster criticises the necessity to build our liferay extensions within the liferay plugins sdk directory itself - which is a bit like modifying the tool you are using while you work with it. I totally agree - and it looks like Liferay IDE is going to fix the issue, so that's another plus point to look forward to.
My first experience with Liferay IDE was with theme projects. My firm has about 20 theme projects and it's just CSS, so it was a good simple point to start. They all just imported nicely into Eclipse, installed simply onto the Liferay server in Eclipse and let me work on the CSS as if I was editing the copy on tomcat itself. I'm not sure I wasn't actually but I think Liferay IDE actually copies the files over when they are saved.
The hook and layout projects installed well too.
However I couldn't import some projects because imports are restricted to projects that follow an undeclared naming convention:
- theme projects must be suffixed -theme
- hook projects must be suffixed -hook
- ext projects must be suffixed -ext
- layout projects must be suffixed -layouttpl
- portlet projects must be suffixed -portlet
I had to import my incorrectly-named extension project as a normal project and then set it up manually as a liferay project to achieve the same effect.
I also have a project in the liferay-plugins-sdk/webs directory - this was the only reference I could find to the webs directory - Hooks and plugins Ext in Liferay which says it's for "regular Java EE web modules". To make this one work, I imported it as a general project and pretended that it was a hook project - I've no idea what the ramifications of that are and so far I haven't had to do anything but deploy the project, and that works alright.
Once I had all my projects set up, I tried deploying them and running liferay. Liferay IDE 1.5.3's handling of ext plug-ins seems to have a bug which means that other plug-ins that depend on it and have an entry in their liferay-plugin-extension.properties's required-deployment-contexts will not deploy because they cannot see that ext is deployed. So I had to ensure that no projects (mostly hooks) had the reference in docroot/WEB-INF/liferay-plugin-extension.properties to the ext plugin or they would not deploy.
I figure the required-deployment-contexts config is set up for the mechanical builds and deploys that we do, but as it is this work-around (deleting the property) is OK for now.
So that's that.
HTH
Regards
Adam
Adam Hardy:
I slowly worked away unguided at the setup and configuration of my plug-in projects and have now got as far as I think is possible with this version of Liferay IDE - v 1.5.3
My greatest fear is that Liferay IDE 1.6.0 will solve the problems I found work-arounds for in 1.5.3 and mean I wasted my time. But that is life, or maybe - that is liferay
I figured I would note down my findings for the benefit of anyone else who wants to use Liferay IDE but gets stuck on some of the issues that I got stuck on.
Let me say at first my appreciation for you doing so. It is a great benefit to the Liferay community and users taking the time to contribute back in this way are the key to the Liferay platform continueing to improve.
Adam Hardy:
First up, this is deployed against Liferay Portal 6.0.6 but I don't think that makes a big difference compared to 6.1. The issues seem to be Eclipse and Liferay IDE-specific.
Also I'm using Eclipse Indigo on Java 1.6.0_30 and Ubuntu as my OS, and I'm using Maven M2E for dependency management and M2E-WTP for dynamic web projects v2.5
I think you know this already but Liferay IDE has zero support for maven style projects or dependency management as of 1.5.3 build. Those pieces are coming in Liferay IDE 2.0, but not in the upcoming 1.6 version.
Adam Hardy:
The liferay-portal installation was pain-free, although the 'clean-appserver' ant target was a bit of a surprise.
Sorry for the confusion. Ext plugin development is the one piece that has the most "black-magic" involved. We have tried to thoroughly document the Ext plugin development process here. http://www.liferay.com/documentation/liferay-portal/6.0/development/-/ai/developing-an-ext-plugin We are always trying to improve documentation like this so let us know where the current document can be improved.
Adam Hardy:
Before using Liferay IDE, I was doing everything on the command line and my worst nightmare was deploying and re-deploying the ext-plugin. It involved hunting down and deleting or removing various files and lines of config in files. Liferay IDE's clean-appserver takes a bold approach - delete the whole liferay portal installation and unzip a fresh clean copy from the downloaded zip! The guys who wrote this stuff must have been listening to Metallica when they wrote that. In actual fact there isn't such a big problem with redeploying everything like themes or JDBC drivers or whatever - you can install that into a clean liferay portal and zip that up so it's there again after nuking it with clean-appserver.
When I installed Liferay IDE and configured it, there were a few little issues that arose. My predecessor had checked in the Liferay plugins sdk directory tree to Perforce source control, but something was wrong with it - Liferay IDE refused to recognise the liferay-plugins-sdk dir where my company's projects are. As a work-around, I just unzipped a fresh copy of the liferay-plugins-sdk-6.0.6 and then fetched my projects out of Perforce straight into it. After my investigations finally led me to download the source code for Liferay IDE, I checked for the error message and discovered these are the pre-requisites that a valid Liferay Plugins SDK has to have:
- build.properties in root directory containing the line "lp.version=6.0.6"
- liferay-plugins-sdk/portlet/build.xml file
- liferay-plugins-sdk/hooks/build.xml
- liferay-plugins-sdk/ext/build.xml
For some reason, what I have in Perforce no longer has a build.properties in the liferay-plugins-sdk root. Fortunately, it doesn't matter what the directory is called - later on I discovered the project directories have to be named with particular suffixes to be imported. Since I have no idea what else was changed in my liferay-plugins-sdk directory before I took it on, I decided the best approach is to copy my whole directory tree over the top of the freshly unzipped download.
There's another thread on this forum here - Thoughts on getting started with Liferay IDE - where the original poster criticises the necessity to build our liferay extensions within the liferay plugins sdk directory itself - which is a bit like modifying the tool you are using while you work with it. I totally agree - and it looks like Liferay IDE is going to fix the issue, so that's another plus point to look forward to.
I agree that adding user projects into the SDK structure is not standard or expected. The current Plugins SDK is just an outgrowth of Liferay's own in-house development efforts that have been using in the project for going on 12 years. They are unlikely to change at this point. With that being said that reason alone is not enough to burden other users in community with the same setup, but alas that is the approach we have taken thus far. We may have been wrong in this. One of the core goals of Liferay from the very beginnging is to be tooling agnostic so that means we never want our users to "have" to use an IDE to get work done. So when I started the Liferay IDE project, I built it to always assume and require the use of the Plugins SDK. My thinking was that if one day a user got upset with Liferay IDE, they could just stop using it and since all of your projects have been forced to be "inside" the SDK then you and your team can continue unabted since all of SDK build scripts will work without modification from commandline. If Liferay IDE allowed uses to be more free-form it would also mean that the projects would be "locked-in" to the IDE in some fashion since it would be needed to fully build and development the plugins. Ie decided early on we didn't want to lock users to IDE so thus we made the choice to force the use of SDK structure for user's project. I will admit after having worked on Liferay IDE for over 2 years I may have made the wrong choice here, so I'm still listening to user's feedback and trying to improve and possibly relaxing this requirement in the future.
One good thing is that if you are fine adopting maven style project with Liferay IDE 2.0 you can be completely free of the SDK and you will still be 100% liferay IDE (2.0) compatibile. But now you will just be locked into maven
Adam Hardy:
My first experience with Liferay IDE was with theme projects. My firm has about 20 theme projects and it's just CSS, so it was a good simple point to start. They all just imported nicely into Eclipse, installed simply onto the Liferay server in Eclipse and let me work on the CSS as if I was editing the copy on tomcat itself. I'm not sure I wasn't actually but I think Liferay IDE actually copies the files over when they are saved.
The hook and layout projects installed well too.
However I couldn't import some projects because imports are restricted to projects that follow an undeclared naming convention:
- theme projects must be suffixed -theme
- hook projects must be suffixed -hook
- ext projects must be suffixed -ext
- layout projects must be suffixed -layouttpl
- portlet projects must be suffixed -portlet
Sorry for this confusion. The naming convention isn't so much as undelcared as it is assumed, but the affect is the same, it leads to confusion. There is an assumption in Liferay IDE that all projects will have been or will be created by the SDK (which the IDE delegates to for project creation). The reason for the assumption (hidden requirement) is that if you look at the SDK scripts for various project types there are lots of places that assume the projects will be named according to their suffix. So in order to pursue 100% compatibility with SDK (one of the core tenets of IDE) this naming convention was a requirement. This restriction will be lifted once Maven projects are supported.
However, one bad problem that does happen in the IDE is that when this problem is met, there is no alerting the user that this indeed is the problem they have run into. I need to improve this asap.
Adam Hardy:
I had to import my incorrectly-named extension project as a normal project and then set it up manually as a liferay project to achieve the same effect.
I also have a project in the liferay-plugins-sdk/webs directory - this was the only reference I could find to the webs directory - Hooks and plugins Ext in Liferay which says it's for "regular Java EE web modules". To make this one work, I imported it as a general project and pretended that it was a hook project - I've no idea what the ramifications of that are and so far I haven't had to do anything but deploy the project, and that works alright.
There is an open ticket for adding support for Web type plugins: http://issues.liferay.com/browse/IDE-479
Adam Hardy:
Once I had all my projects set up, I tried deploying them and running liferay. Liferay IDE 1.5.3's handling of ext plug-ins seems to have a bug which means that other plug-ins that depend on it and have an entry in their liferay-plugin-extension.properties's required-deployment-contexts will not deploy because they cannot see that ext is deployed. So I had to ensure that no projects (mostly hooks) had the reference in docroot/WEB-INF/liferay-plugin-extension.properties to the ext plugin or they would not deploy.
I figure the required-deployment-contexts config is set up for the mechanical builds and deploys that we do, but as it is this work-around (deleting the property) is OK for now.
So that's that.
HTH
Regards
Adam
Thanks Adam this does help. So what would you see is the top 1 or 2 action items from this discussion? I would assume that relaxing the requirement for creating projects outside the SDK would be one. However, there are so many things that begin to fail with the current SDK build scripts like (service builder, build wsdd, etc). One solution would be for me to push to get the SDK modernized (allow free-form projects) but the intertia against this would not be trivial. Switching to full mavenized projects (once they are fully supported in IDE) would likely be a better option for your team.