Upgrading Your EXT Environment to an EXT Plugin
Company Blogs March 9, 2010 By Edward Shin Staff
Update: Please see the official documentation here:
Now that we have EXT Plugins, the million dollar question is what will happen to the EXT Environment?
First, let's cover the bad news. The EXT Environment will no longer exist in Liferay 6.0.
For those of you that use the EXT Environment primarily to change core code, this is a good thing because EXT Plugins handle core customizations better than the EXT Environment. You'll spend less time deploying and maintaining your changes with EXT plugins. See Introducing EXT Plugins! for more information.
For those of you (like me) that have made heavy customizations in the EXT Environment including custom portlets and services, you're probably a little nervous about this change.
The good news is that we have a script to help migrate your EXT Environments to EXT Plugins.
You can find the build.xml script in the Plugins SDK in trunk in the "ext" directory:
What the script does is create an EXT Plugin from the ext.zip file and merge in your changes from your EXT Environment.
Let's take a look at how this works in practice.
Assuming that your EXT Environment is located in /Users/ed/projects/ext:
(The Windows equivalent would be C:/projects/ext)
We can run the following command to migrate the code from the EXT Environment to EXT Plugins:
ant upgrade-ext -Dext.dir=/Users/ed/projects/ext -Dext.name=hello-world -Dext.display.name="Hello World"
-Dext.dir is a command line argument to the location of the EXT Environment
-Dext.name is the name of the EXT Plugin that you want to create
-Dext.display.name is the display name (See liferay-plugin-package.properties)
This will create a hello-world-ext directory with the merged changes from your EXT Environment.
Both build-service (ServiceBuilder) and build-db (DBBuilder) have been ported to EXT Plugins to allow developers to regenerate their services and SQL code in EXT Plugins:
But as noted in the warning message, ServiceBuilder in EXT plugins will be deprecated in future versions, and custom services should be migrated to portlet plugins. Try to migrate your custom services to portlet plugins as soon as possible as this is the recommended practice.
1. "build-services" in the above example is a custom target. You can define custom targets like this in order to make them work properly with Service Builder:
<param name="service.file" value="docroot/WEB-INF/ext-impl/src/com/test/service.xml" />