Converting Your Application's Service Builder API and Implementation

In this tutorial, you’ll learn about converting a Liferay Portal 6 Service Builder application to a Liferay DXP 7.1 style application. In the previous tutorial, you learned how to generate your implementation and API modules. If you haven’t yet run the service-builder Blade CLI command outlined in step 2 of the previous tutorial, run it now. The API module holds your application’s Service Builder-generated API and the implementation module holds your application’s Service Builder implementation.

Before you begin editing the API and implementation modules, you must configure your root project (e.g., tasks) to recognize the multiple modules residing there. A multi-module Gradle project must have a settings.gradle file in the root project for building purposes. When you generated your Service Builder project’s modules using Blade CLI, the settings.gradle file was inserted and pre-configured for the api and service modules. You should add your web module into the Service Builder project’s generated parent folder and define it in the settings.gradle file too. You’ll configure your web module via Gradle settings later, but for now, copy the module into the project generated by the service-builder template. An example tasks project’s root folder would look like this:

• tasks
  • gradle
  • tasks-api
  • tasks-service
  • tasks-web
  • build.gradle
  • gradlew
  • settings.gradle

Your root project folder should now be in good shape. Next, use Service Builder to generate your application’s service API and service implementation code.

1. Copy your traditional application’s service.xml file into the implementation module’s root folder (e.g., tasks/tasks-service).

2. Blade CLI generated a bnd.bnd file for your service implementation module. Edit this bnd.bnd file to fit your application. For an example of a service implementation module’s bnd file, examine the export-import-service module’s bnd below:

   Bundle-Name: Liferay Export Import Service
   Bundle-SymbolicName: com.liferay.exportimport.service
   Bundle-Version: 4.0.0
   Export-Package:\
       com.liferay.exportimport.content.processor.base,\
       com.liferay.exportimport.controller,\
       com.liferay.exportimport.data.handler.base,\
       com.liferay.exportimport.lar,\
       com.liferay.exportimport.lifecycle,\
       com.liferay.exportimport.messaging,\
       com.liferay.exportimport.portlet.preferences.processor.base,\
       com.liferay.exportimport.portlet.preferences.processor.capability,\
       com.liferay.exportimport.search,\
       com.liferay.exportimport.staged.model.repository.base,\
       com.liferay.exportimport.staging,\
       com.liferay.exportimport.xstream
   Liferay-Releng-Module-Group-Description:
   Liferay-Releng-Module-Group-Title: Data Management
   Liferay-Require-SchemaVersion: 1.0.0
   -includeresource: content=../../staging/staging-lang/src/main/resources/content
   

3. Blade CLI also generated your service implementation module’s build.gradle file. In this file, Service Builder is already configured to generate code both in this module and in your service API module. When you run Service Builder, Java classes, interfaces, and related files are generated in your *api and *service modules. Open your service implementation module’s build.gradle file to view the default configuration.

   As you’ve learned already, you don’t have to accept the generated build files’ defaults. Blade CLI simply generated some standard OSGi and Liferay configurations.

   For example, Service Builder is already available for you by default. Blade CLI applies the Service Builder plugin automatically when a project contains the service.xml file. With the Service Builder plugin already available, you don’t have to worry about configuring it in your project.

4. Another important part of your service implementation module’s build.gradle file is the buildService{...} block. This block configures how Service Builder runs for your project. The current configuration generates your API module successfully, but extra configuration might be necessary in certain cases.

5. Navigate to your root project folder. Then run gradlew buildService.

   Your service API, implementation classes, and configuration (SQL, Hibernate, Spring, etc.) are generated from your service.xml file in their respective modules. The Service Builder Gradle Plugin has multiple options.

6. Now that you’ve run Service Builder, copy your business logic classes into your implementation module. The table below highlights popular Liferay Portal 6 classes and packages and where to place them in your application. This table suggests how to organize your classes and configuration files; however, remember to follow the organizational methodologies that make the most sense for your application. One size does not fit all with your modules’ folder schemes.

   Plugin Package	Module Package
   tasks-portlet/docroot/WEB-INF/src/com.liferay.tasks.model.impl	tasks-service/src/main/java/com.liferay.tasks.model.impl
   tasks-portlet/docroot/WEB-INF/src/com.liferay.tasks.service.impl	tasks-service/src/main/java/com.liferay.tasks.service.impl
   tasks-portlet/docroot/WEB-INF/src/com.liferay.tasks.service.permission	tasks-service/src/main/java/com.liferay.tasks.service.permission
   tasks-portlet/docroot/WEB-INF/src/com.liferay.tasks.service.persistence.impl	tasks-service/src/main/java/com.liferay.tasks.service.persistence.impl
   tasks-portlet/docroot/WEB-INF/src/com.liferay.tasks.social	tasks-service/src/main/java/com.liferay.tasks.social
   tasks-portlet/docroot/WEB-INF/src/com.liferay.tasks.util	tasks-service/src/main/java/com.liferay.tasks.util
   tasks-portlet/docroot/WEB-INF/src/custom-sql	tasks-service/src/main/resources/META-INF/custom-sql

7. Once you’ve copied your business logic, run gradlew buildService again to generate the remaining services.

Now that your services are generated, you must wire up your modules so they can reference each other when deployed to Liferay’s OSGi container. Blade CLI has already partially completed this task. For example, it assumes that the service implementation module depends on the service API module.

You still need to associate the client module with the api and service modules, since they were generated separately. To do this, follow the steps below:

1. In your root project’s settings.gradle file, add the web module with the api and service modules so it’s included in the Gradle build lifecycle:

   include "tasks-api", "tasks-service", "tasks-web"
   

2. Add the api and service modules as dependencies in you client module:

   dependencies {
       compileOnly  project(':tasks-api')
       compileOnly  project(':tasks-service')
   }
   

Excellent! You’ve successfully generated your application’s services using Service Builder. They now reside in modules, and can be deployed to Liferay DXP 7.1.