« Back to Development (Legacy)

Extension Environment

This article is Legacy. For more updated information, please see Ext Plugin.

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/ and portal-impl/, ext-web/ and 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 jars and war files that encapsulates 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.e. you could place your portal-ext.properties in ext-impl/classes/ and expect it to be jar'd into ext-impl.jar. Same goes for your ext-spring-professional.xml - ext-impl/classes/META-INF). 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).

Most users are now using the auto deploy feature, 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", it would deploy your theme war to your deploy directory, the same applies to portlet wars as well - ext/portlets.

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.

0 Attachments
69978 Views
Average (0 Votes)
The average rating is 0.0 stars out of 5.
Comments
Threaded Replies Author Date
does "ant deploy" deploy just the changes you... Ziggy © August 11, 2009 11:48 AM
It does build for all the files.. but all of... Raja Nagendra Kumar September 17, 2009 6:34 AM
This may be a silly question, but at runtime,... Tom Witmer October 8, 2009 3:46 PM

does "ant deploy" deploy just the changes you made or every file is redeployed?
Posted on 8/11/09 11:48 AM.
It does build for all the files.. but all of them are done at build time.. one need not put the all the files ine xt.. just need to put what is changed.. rest of them are taken as is from jar files.
Posted on 9/17/09 6:34 AM in reply to Ziggy ..
This may be a silly question, but at runtime, how does the extension environment override the built-in portal classes? This would be simple if the ext classes were simply copied into portal-impl.jar, but they're not. Somehow, the classes in ext-impl.jar are always invoked before the classes in portal-impl.jar. How is this enforced?
Posted on 10/8/09 3:46 PM.