An application builder to allow you to construct starter applications for building your projects with Liberty.
Liberty app accelerator is still in its early stages so we will be adding new technologies and capabilities to the page over time. For now, feel free to try it out and see how quickly you can have a fully fledged application. If you have any questions, comments or suggestions please raise an issue on our GitHub repository.
For an introduction see our blog post. To learn how the Liberty Starter can be used to create the image service for the Plants by WebSphere evolution from monolith to microservice, see our new article.
The current technologies we have are:
This provides you with the jaxrs-2.0 feature and the jsonp-1.0 feature.
Inside the project produced there is a application.rest package containing the LibertyRestEndpoint
class. This adds a REST endpoint which you can access at /rest. There is also a test class named it.rest.LibertyRestEndpointTest
that will test the REST endpoint to ensure it is working.
For the complete feature documentation, see the (jaxrs-2.0)[http://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_feature_jaxrs-2.0.html] feature description in IBM Knowledge Center.
This provides you with the servlet-3.1 feature.
Inside the project there is a application.servlet package containing the LibertyServlet
class. This adds a servlet with an endpoint which you can access at /servlet. There is also a test class named it.servlet.LibertyServletTest
that will test the servlet's endpoint to ensure it is working.
For the complete feature documentation, see the servlet-3.1 feature description in IBM Knowledge Center.
This provides you with a SpringBoot application that will run on WebSphere Liberty.
Inside the project there is a application.springboot.web package containing two classes:
- SpringBootLibertyApplication: The entry point for the SpringBoot application.
- LibertyHelloController: A Spring REST endpoint which you can access at /springbootweb.
There is also a test class named it.springboot.web.HelloControllerTest
that will test the Spring REST endpoint to ensure it is working.
This provides you with the websocket-1.1 feature.
For the complete feature documentation, see the websocket-1.1 feature description in IBM Knowledge Center.
This provides you with jpa-2.1. For the complete feature documentation, see the jpa-2.1 feature description in IBM Knowledge Center.
The Watson SDK provides an API for accessing Watson Services. For the complete documentation, take a look at the Watson developer pages and the Watson SDK github project.
The MicroProfile project is an open community with the aim of optimizing Enterprise Java for a microservices architecture. MicroProfile will be evolving with guidance from the community.
If you want to share your thoughts you can post straight to the MicroProfile Google group.
For the complete feature documentation, see the microProfile-1.0 feature feature description in IBM Knowledge Center.
Swagger is a simple yet powerful representation of RESTful APIs.
This provides you with the apiDiscovery-1.0 feature, which allows you to discover REST APIs that are available on the Liberty server and then invoke the found REST endpoints using the Swagger user interface.
You can also easily expose the REST endpoints available from your web modules running on Liberty server by documenting the endpoints using the Swagger 2.0 Specification.
It is also possible to follow a design-first approach by creating the Swagger documentation first and then generating the server code from it.
For the complete feature documentation, see the apiDiscovery-1.0 feature description in IBM Knowledge Center.
Once you have downloaded the project, to build it you just need to run the command gradle clean build
in the top level project. To run the application locally from the root project run liberty-starter-application:localRun
. The application should be available at http://localhost:9082/start.
The project is split up into several different pieces.
liberty-starter-application
contains the code to build the main application including the code for the UIliberty-starter-common
contains common api code for the projectsliberty-filter-application
is a simple war that redirects people to the context/start
liberty-starter-wlpcfg
contains the Liberty usr directory where the logs and apps for the app accelerator will be put after a buildliberty-starter-test
contains a test microservice used during the testing phase
There are then a set of starter-microservice-techId
projects that contain the code for the individual technology types.
If you are running locally you will be required to register the application with GitHub and provide the client id and secret as well as an extra app accelerator secret (for signing the state sent to GitHub) as environment variables.
To do this go to GitHub's OAuth applications page. Register your application with the following settings:
- Application Name: Anything you want
- Homepage URL:
http://localhost:9082/start
- Application description: Anything you want
- Authorization callback URL:
http://localhost:9082/start/api/v1/github/callback
Once you have done this GitHub will give you a client ID and client secret set the following environment variables prior to starting the server:
- gitHubClientId
- gitHubClientSecret
- appAcceleratorSecret (this can be anything you want it to be)
There are two deployment options for the app accelerator: local and Bluemix
If you have chosen the local deployment option when you run mvn install
the application will be compiled, tested and then the application will start at localhost:9080/mylibertyApp. To stop the application run mvn clean -P stopServer
. This will stop the server and clean up the target directories.
To deploy an application to Bluemix you first need a Bluemix account. Once you have created a Bluemix account you can build and deploy your application by running mvn install -Dcf.org=[your email address] -Dcf.username=[your username] -Dcf.password=[your password]
. Where cf.org
is the Bluemix organization you want to deploy to and cf.username
and cf.password
are your credentials for Bluemix. Once the build has been run see your command line output to find the endpoint for your application or look for it in the Bluemix dashboard.
You can optionally supply the following Bluemix configurations in the command line or in the top level pom.xml:
- <cf.context>eu-gb.mybluemix.net</cf.context>
- <cf.target>https://api.eu-gb.bluemix.net</cf.target>
- <cf.space>dev</cf.space>
- <cf.context.root>${cf.host}.${cf.context}/${warContext}</cf.context.root>
If you have chosen the deployment type on the app accelerator you can specify a different deployment type on the command line as follows:
mvn install -P localServer
for local deploymentmvn install -P bluemix
for Bluemix deployment
To see an example of everything you can include in a technology see the starter-microservice-test project. This is the example project we use to test the main piece of the app against.
If you want to add changes to the app accelerator, create a fork of the project and then once you are happy with the change create a pull request to the "staging" branch. We will use this branch to run some testing before pushing the changes live.
-
Copy the contents of the
starter-microservice-template
directory into a new directory. The convention is that the last part of the name is related to the technology. So, if you were creating a technology based onSuperTech
then the directory would bestarter-microservice-supertech
. (SuperTech will be the name used for the rest of these instructions). -
Update the id's and context root in the
build.gradle
file. The context root would change to/supertech
, the id in theinstallAllPoms
task would besupertech
and the id in thefvt
task would bestarter-microservice-supertech
. -
Change the group ID values in the POM files under
starter-microservice-supertech/repository/0.0.1
, compile-pom.xml, provided-pom.xml and runtime-pom.xml. net.wasdev.wlp.starters.template becomes net.wasdev.wlp.starters.supertech. -
Refactor the packages and classes under src to SuperTech i.e.
starter-microservice-supertech/src/main/java/com/ibm/liberty/starter/service/template
becomesstarter-microservice-supertech/src/main/java/com/ibm/liberty/starter/service/supertech
-
Change the
GROUP_SUFFIX
constant in theProviderEndpoint
class tosupertech
. -
Change the value of
context-root
insrc/main/webapp/WEB-INF/ibm-web-ext.xml
tosupertech
. -
Edit
src/main/webapp/WEB-INF/classes/description.html
to tell everyone about how SuperTech works and it's benefits. -
(If you don't want to provide sample code for your technology type skip to step 10). Put the application sample code into
src/main/webapp/sample
. -
Put the Liberty configuration for the sample application into
src/main/webapp/sample
. -
Change the tests package to
src/test/java/com/ibm/liberty/starter/service/supertech/api/v1/it
and then the test classes to expect the correct responses for SuperTech.
-
In
liberty-starter-application/src/main/resources
update the services.json file to add your new technology, including an id, name, description and the endpoint you want to use. This will add your technology as an option on the main page. -
By convention the id should be
supertech
and the endpoint should be/supertech
. -
The name and description are used in the UI to give the user information about the technology type.
-
In the settings.gradle file add
starter-microservice-supertech
to theinclude
list. This will add your project into the build lifecycle. -
In the build.gradle file in
liberty-starter-application
in the last set ofdependsOn
commands add your technology to thewar.dependsOn
list. You need to add:nameOfYourProject:publishWar
. This will make sure your project is built before theliberty-starter-application
project. -
In
liberty-starter-wlpcfg/servers/StarterServer/server.xml
add your application to the list. You need to provide the name of the war file being created in location, the context-root that matches the endpoint specified in theservices.json
file in step 1 and the id you specified in step 1.
If you run gradle clean build
your new project should now be built and the war should be put into the apps directory of your server.