This wiki does not contain official documentation and is currently deprecated and read only. Please try reading the documentation on the Liferay Developer Network, the new site dedicated to Liferay documentation. DISCOVER Build your web site, collaborate with your colleagues, manage your content, and more. DEVELOP Build applications that run inside Liferay, extend the features provided out of the box with Liferay's APIs. DISTRIBUTE Let the world know about your app by publishing it in Liferay's marketplace. PARTICIPATE Become a part of Liferay's community, meet other Liferay users, and get involved in the open source project. Suggestions and questions
Table of Contents [-]
Introduction #
The best way to think about the extension environment is as a wrapper for our core source. In most cases, it mirrors our core source directories (i.e. ext-impl/ mirrors portal-impl/, ext-web/ mirrors portal-web/). It allows you to develop on top of our portal, like a platform, without having to worry about upgrading in the future.
How does this work? #
Within your ext environment, we have a directory called ext-ear/. Within that directory, we have both jar and war files that encapsulate all of our core source. What that means is that you could deploy and run LifeRay with just the ext environment alone. For instance, all of the class files from our core are included in portal-impl.jar. By using the ext environment, you get the LifeRay ant deployment scripts out-of-the-box, meaning you can create your java classes in ext-impl/ and simply do an ant deploy to compile and deploy them for you.
It'll provide you a directory structure that you can then check in to a code repository as well.
| I don't quite see the connection here between code repository and jar file (in following parentheses). Could you explain this please? |
(i.e. you could place your portal-ext.properties in ext-impl/classes/ and expect it to be jar'd into ext-impl.jar. Similarly, you could place your ext-spring-professional.xml in ext-impl/classes/META-INF).
| For instance, I can check my ext directory structure into a code repository whether I check in the generated jar files or not, so I don't see what you are getting at. |
The ext environment also has a web.xml that you can manipulate. What this means for you: you could have all your classes, config files, xml files, all under one roof (or directory specifically).
| Question: Why does it mean this? |
Most users are now using the auto deploy feature,
| I don't think I understand auto deploy. I thought ant deploy was used in, say, the plugins sdk to deploy the war file to the relevant auto deploy directory. Is there some other auto deploy method? |
but you could also use ant to deploy within our ext environment as well. If you were to drop your war into ext/themes/ and then do an ant deploy,
| Question: From the top-level ext build.xml? |
it would deploy your theme war to your deploy directory, the same applies to portlet wars placed in ext/portlets.
| Note here that the directories ext/themes and ext/portlets are not created in the process of building the ext environment from the portal source using ant build-ext. |
Finally, using the ext environment means that you can develop your portlets as an extension of our source. Meaning, you could build your portlets as if you were writing them for our core. This means you wouldnt have to build war files for your portlets. On top of the fact, you could then leverage all of our utility classes and tags as well.
Pre-4.3 #
Prior to the advent of Liferay v4.3, the portal-impl/ was known as the portal-ejb/ and the ext-impl/ as the ext-ejb/. This naming convention was changed due to the choice to remove EJBs entirely from Liferay as of v4.3.
