Forums

Home » Liferay IDE » English

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Adam Hardy
Getting ext and a dependent hook plugin going
June 27, 2012 5:28 AM
Answer

Adam Hardy

Rank: New Member

Posts: 19

Join Date: May 18, 2012

Recent Posts

I know you guys at Liferay are busy with the Eclipse Juno release but I would really appreciate some help on this!

I am trying to get Liferay IDE to deploy an extension project along with a hook project that depends on some of the classes in the ext project. Basically it's a third party hook and extension project where we have incorporated the extension project into our own extension project. The project will deploy from the command line with the usual ant scripts and stop/start cycles.

In Eclipse though, Liferay says on the server log that the ext project isn't loaded so the hook project will sit in the queue.

1
215:10:16,240 INFO  [HotDeployEvent:95] Plugin device-rules-hook requires fis-ext-mobile
315:10:16,240 INFO  [HotDeployUtil:137] Queueing device-rules-hook for deploy because it is missing fis-ext-mobile


I can see the ant script output where fis-ext-mobile is getting deployed, but it doesn't give me any clues what the problem is:

 1
 2[Console output redirected to file:/home/adahar/workspace-indigo/.metadata/.plugins/com.liferay.ide.eclipse.sdk/sdk.log]
 3Buildfile: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/build.xml
 4compile:
 5compile-with-global-class-loader:
 6    [mkdir] Created dir: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-service/classes
 7compile-java:
 8    [javac] Compiling 41 source files to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-service/classes
 9    [javac] Note: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-service/src/com/nomadsoft/cortex/infrastructure/theme/service/persistence/ThemeParameterUtil.java uses unchecked or unsafe operations.
10    [javac] Note: Recompile with -Xlint:unchecked for details.
11compile-with-global-class-loader:
12    [mkdir] Created dir: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-bridges/classes
13compile-java:
14     [copy] Copying 1 file to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-bridges/classes
15compile-with-global-class-loader:
16    [mkdir] Created dir: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-java/classes
17compile-java:
18     [copy] Copying 1 file to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-java/classes
19compile-with-portal-class-loader:
20    [mkdir] Created dir: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-taglib/classes
21compile-java:
22     [copy] Copying 1 file to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-taglib/classes
23compile-with-portal-class-loader:
24    [mkdir] Created dir: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/classes
25compile-java:
26    [javac] Compiling 39 source files to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/classes
27    [javac] Note: Some input files use unchecked or unsafe operations.
28    [javac] Note: Recompile with -Xlint:unchecked for details.
29     [copy] Copying 8 files to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/classes
30war:
31      [jar] Building jar: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-service/ext-service.jar
32war-util:
33      [jar] Building jar: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-bridges/ext-util-bridges.jar
34     [copy] Copying 1 file to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/classes/com/liferay/portal/deploy/dependencies
35war-util:
36      [jar] Building jar: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-java/ext-util-java.jar
37     [copy] Copying 1 file to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/classes/com/liferay/portal/deploy/dependencies
38war-util:
39      [jar] Building jar: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-util-taglib/ext-util-taglib.jar
40     [copy] Copying 1 file to /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/classes/com/liferay/portal/deploy/dependencies
41      [jar] Building jar: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-impl/ext-impl.jar
42      [zip] Building zip: /home/adahar/projects/LiferayExt/dist/fis-ext-mobile-6.0.6.DEV.war
43   [delete] Deleting: /home/adahar/projects/LiferayExt/ext/fis-ext-mobile/docroot/WEB-INF/ext-fis-ext-mobile.xml
44direct-deploy:
45     [copy] Copying 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/lib/ext
46     [copy] Copying 4 files to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib
47     [copy] Copying 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib
48     [copy] Copying 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib
49     [copy] Copying 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib
50     [copy] Copying 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib
51     [copy] Copying 23 files to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT
52     [java] Loading jar:file:/home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/system.properties
53     [java] Loading jar:file:/home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/portal.properties
54     [java] Loading jar:file:/home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/com/liferay/portal/tools/dependencies/portal-tools.properties
55     [java] 12:18:09,279 INFO  [PortalImpl:278] Global lib directory /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/lib/ext/
56     [java] 12:18:09,282 INFO  [PortalImpl:298] Portal lib directory /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/lib/
57     [move] Moving 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF
58    [unzip] Expanding: /home/adahar/projects/LiferayExt/dist/fis-ext-mobile-6.0.6.DEV.war into /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT
59deploy-properties:
60     [copy] Copying 1 file to /home/adahar/soa/liferay-portal-6.0.6/tomcat-6.0.29/webapps/ROOT/WEB-INF/classes
61BUILD SUCCESSFUL
62Total time: 14 seconds


I can then see some logging output from a MessageListener in the ext project which gets activated - so I know it (or some of it) is getting deployed.

But the key part is, the ext project isn't making its presence felt in the HotDeploy class that registers its absence when deploying the hook project.

Thanks
Adam Hardy
RE: Getting ext and a dependent hook plugin going
July 6, 2012 6:34 AM
Answer

Adam Hardy

Rank: New Member

Posts: 19

Join Date: May 18, 2012

Recent Posts

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 emoticon

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:

  1. build.properties in root directory containing the line "lp.version=6.0.6"
  2. liferay-plugins-sdk/portlet/build.xml file
  3. liferay-plugins-sdk/hooks/build.xml
  4. 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
Gregory Amerson
RE: Getting ext and a dependent hook plugin going
July 8, 2012 10:38 PM
Answer

Gregory Amerson

LIFERAY STAFF

Rank: Liferay Master

Posts: 921

Join Date: February 16, 2010

Recent Posts

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 emoticon

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:

  1. build.properties in root directory containing the line "lp.version=6.0.6"
  2. liferay-plugins-sdk/portlet/build.xml file
  3. liferay-plugins-sdk/hooks/build.xml
  4. 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 emoticon

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.
Adam Hardy
RE: Getting ext and a dependent hook plugin going
July 11, 2012 2:55 AM
Answer

Adam Hardy

Rank: New Member

Posts: 19

Join Date: May 18, 2012

Recent Posts

My main problem that really slowed me down was the guesswork and learn-by-doing I had to go through without documentation. The docs you pointed me at are good but not for this kind of stuff.

But working with Liferay IDE and deploying new code with just a click etc etc, compared to our previous build, test and deploy cycle - the difference is like night and day. Now I've got the installation and configuration setup documented, none of it's a problem anymore. Yes it's slow but it's only a matter of an hour or so longer than it should be but that's a price well worth paying to get it up and running.

What did surprise me was that there doesn't seem to be anyone else doing this, no-one out there trying to get Liferay IDE working in a big development environment - at least nobody who would contribute on the forum or who put anything up on blogs or stackoverflow.com or anywhere.

I think I agree pretty much with your priorities - version 2.0 sounds very promising. There are some small changes you can put in the code to tell people what the problem is, e.g. the suffixes on the project names. But concentrating on v2.0 and getting maven integration sorted out would be ideal.

How exactly would you lock yourself in to maven? That's obviously not ideal. There are build tools like gradle which more and more people are going to be working with in future.

.. and sorting out a seperate project and liferay-ext-plugin directory structure would be good - for v2.0 I mean.