Skip to main content
Jump to: navigation, search

Lyo/creating OSLC4J project

< Lyo

Eclipse Setup

Make sure your environment is setup for OSLC4J development as instructed on General Setup for OSLC4J development

Sample Projects

As a complement when following the instructions below, you can find sample projects under the Lyo Adaptor Sample Modelling git repository.

Create an OSLC4J project

The steps below guide you through the necessary steps of creating an Eclipse project with the necessary configurations to develop any OSLC4J adaptor.

In the instructions below, we assume the following parameters, which you will need to adjust for your particular project:

  • Eclipse Project Name: adaptor-sample-webapp
  • Base Package Name for Java Classes: com.sample.adaptor

We will here only create the code skeleton. The Toolchain Modelling and Code Generation Workshop can then be used to generate the necessary code to become a fully functional adaptor.

Creation of the skeleton consists of 2 steps:

  1. creating a Maven project from an archetype
  2. customising the generated project with the Lyo-specific configuration

Creating a Maven project from an archetype

To create a Maven project from an archetype via Eclipse

  1. select File -> New -> Other
  2. then select Maven Project under Maven group.
  3. Leave the Create a simple project checkbox unchecked.
  4. Uncheck the Use default Workspace location option and point it to the project root
  5. Press Next
CreateMavenAdaptorProject Step1.png

Next, select the maven-archetype-webapp archetype:

CreateMavenAdaptorProject Step2.png

Next, Fill in the Group Id, Artefact Id, and the Package Base.

  • The Package Base value (com.sample.adaptor on this page) will be used as a base package for your adaptor code.
CreateMavenAdaptorProject Step3.png

You should now have the project in Eclipse and the following folder structure:

CreateMavenAdaptorProject CodeStructure.png

Customise the project POM file

We now need to modify the project pom.xml file.

General POM changes

We need to make sure our project uses UTF-8 and JDK 1.8. We will also use properties to define a common version for Lyo Core and Lyo Server packages:


Java EE 6

We require Java EE 6 or higher and JSTL:


Lyo repositories

an OSLC4J project will use Lyo dependencies that we need to declare. Before we can do that, we need to add the Lyo repository. After that, we are ready to add the dependencies.

      <name>lyo-releases repository</name>

SLF4J package dependencies

Lyo uses SLF4J for logging, leaving the choice of the actual logging library to use. We will use the simplest option:


Lyo package dependencies

Lyo dependencies need:


OAuth support

Finally, your adaptor might need to includes the experimental support for OAuth:

Exclusions are due to the Bug 513477
OAuth is enabled by default. If you want to disable it, open the generated Application class and do the following changes:
  • comment out line RESOURCE_CLASSES.add(Class.forName(""));
  • comment out line RESOURCE_CLASSES.add(Class.forName(""));
  • change catch (ClassNotFoundException e) to catch (Exception e)

OSLC Client support

If you use OAuth or consume any resources in your Adaptor Interface, an OSLC client dependency is needed:


Embedded Jetty server for quick debugging

Finally, you should use an embedded servlet container during the debugging to simplify the development process.

Replace the existing <build> entry with the Jetty configuration below, using the following customisations:

  • adaptor-sample is the context path that can be the same as your eclipse project name (or something more appropriate)
  • 8080 is the port number you want to run the services on.

This will make your adaptor available under the path http://localhost:8080/adaptor-sample

        <stopKey />
        <stopPort />

Customise the web configuration

Modify the parameters in /src/main/webapp/WEB-INF/web.xml according to the template below.

  • Adaptor Sample could be the same as your eclipse project name (or something more appropriate)
  • com.sample.adaptor should be the same as the base package name for your project.
  • 8080 should match the port number specified in the POM file for Jetty configuration.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi=""
  id="WebApp_ID" version="3.0">
  <display-name>Adaptor Sample</display-name>
    <description>Base URI for the adaptor.</description>
    <description>Listener for ServletContext lifecycle changes</description>
    <servlet-name>JAX-RS Servlet</servlet-name>
    <servlet-name>JAX-RS Servlet</servlet-name>

Final tips

If you get the error Project configuration is not up-to-date with pom.xml, simply right click on the eclipse project and select Maven–>Update Project …

Run the adaptor

Once the adaptor is developed, you can run it by selecting Run As –> Maven build … from the project’s context menu, and setting the goal to clean jetty:run-exploded.

You can now access your adaptor from http://localhost:8080/adaptor-sample

  • adaptor-sample and 8080 will depend on your particular settings, as instructed above.

OpenApi/Swagger Support (Optional)

Being already a REST web server, an OSLC4J project can relatively easily be documented using OpenApi/Swagger.

The instructions below provide the minimal settings necessary for an OSLC4J project.

  • Additional suggestions are also provided, given that a typical OSLC4J project might differ from that assumed by OpenApi/Swagger.
  • One major difference is the fact that OSLC assumes an RDF data model, where resources are defined using OSLC Shapes. Swagger/OpenApi does not explicitly recognise such a model.

The instructions below are based on Swagger Core JAX RS Project Setup 1.5.X, compiled for a typical OSLC4J project, as instructed in this wiki.

Add Maven dependencies

Add the following Swagger dependency to your maven pom.xml file


Add Swagger-Core’s JAX-RS Providers to your Application

Add swagger-core’s providers to the OslcWinkApplication class of your server.

public class Application extends OslcWinkApplication {
  private static final Set<Class<?>> RESOURCE_CLASSES = new HashSet<Class<?>>();

Configure Swagger’s Servlet in the web.xml

Add the following to your web.xml:

  • swagger.api.basepath depends on your particular settings, as instructed above.

Add OpenApi Annotations (Almost Optional)

The OpenApi documentation can be achieved with as little as adding @Api to each REST/OSLC service in your project. This is detailed in the first step below. While the remaining intructions are optional, they are highly recommended to provide a documentation that can best reflect the OSLC services.


  1. For each REST service (ie. OSLC Service), simply add the @Api annotation.
  2. (OPTIONAL) add the value and description details. The value is used to group the REST methods into common categories, helping in the structuring of the methods in the documentaton. You can give it the same value as that of the @Path annotation, collecting all REST methods for the same service together.
@Api(value = "requirements", description = "OSLC service for resources of type" + "Requirement")

@ApiOperation (Optional)

For each REST method, add the @ApiOperation Swagger annotation.

Important: In OpenApi, an operation is defined as unique through the combination of its path and method. This means that two C.R.U.D. methods for the same path are not allowed – even if they have different parameters (including Accept and Content-Type annotations).

  • Example: Your OSLC Service may define two different Java methods to separately handle HTML and RDF/XML content types. OpenApi will only recognise one of these two methods, while ignoring the other.
  • Workaround: Annotate ALL methods that are identified as unique with the complete list of media types in the produces property of the @ApiOperation annotation. This way, the generated documentation correctly indicates the existance of all methods.
    @ApiOperation(value = "GET on Requirement resources",
        produces = OslcMediaType.APPLICATION_RDF_XML + ", " + MediaType.TEXT_HTML)
    public Requirement getRequirement(

@ApiModel (Optional)

For each Java class that models an OSLC-resource (@OslcName annotation), add an @ApiModel annotation that refers to the Shape of the resource, since a Shape is a more accurate description of the object, than the one automatically generated by Swagger.

@ApiModel(description = "The  model below is only a object structure as derived by swagger.  For a more accurate RDF Description, refer to the Requirement Resource Shape.")
@OslcResourceShape(title = "Requirement Resource Shape", describes = Oslc_rmDomainConstants.REQUIREMENT_TYPE)
public class Requirement 

Access the Swagger Documentation

You are done! You should now be able to access the the OpenAPI specification document (yaml file) at:


You can copy the yaml file to a Swagger Editor, to view the API documentation, as well as generate client/Server SDK code for a number of languages and platforms.

But, with a few more steps, you can also integrate Swagger UI into your OSLC server, providing the end-user with an interactive console of the OSLC services.

Integrating Swagger UI

The following steps allows you to integrate Swagger UI into your OSLC server, to provide the end-user with a visual and interactive presentation of the OSLC services.

  1. Download and extract the Swagger UI GitHub project onto your local computer.
  2. Copy the content of the ‘dist’ folder to ‘/src/main/webapp/swagger-ui’, under your web project.
  3. Edit the ‘swagger-ui/index.html’ file, replacing the url ‘’ with the url of your own yaml file ‘http://localhost:8080/adaptor-sample/services/swagger.yaml’

You are done! The generated interactive API console can now be accessed via


Back to the top