Development

SW360 Development Information

Developing sw360

The sw360 is Java-based application consisting of two main parts:

  1. A Liferay/based front end application that allows users to work with sw360
  2. A Java-based servlet infrastructure Thrift interfaces that allows the Liferay part and other applications to manage and store data
  3. In the backend, couchdb is used for storing project, component, release and license information as well as attachments.

Submitting Issues

Please report issues to the issue tracker, but please keep also in mind that someone else has to read them! Issues should include:

  • What you intended to do?
  • What did you observe?
  • Why do you think it is wrong?
  • Screenshots of what you have observed presumably gone wrong or link to pages were another person can follow
  • Version where you have observed this.
  • Common written English and use of line breaks!!! Use the preview function!

Please refer to the following pages for writing issues:

Contribution Workflow

As basic introduction, the dev ops works as following:

  1. We are issue-based, please do not hesitate to create issues - also for questions (and set the issue tag)
  2. The issues are organised by milestones which do not represent releases anymore. Milestone are meant to be useful packages of work done
  3. Contributions are made through pull requests
  4. We do conversations directly on issues and pull requests

More topics regarding “how” to develop:

  1. Definition of done and code style
  2. Creating a sw360 release
  3. Brief notes on the jgiven testing
  4. For help with problems, you might want to check that

Architecture

sw360 is a server application using Java servlets. It did some faint steps towards micro services (ie. one maintaining licenses, another for vulnerabilities), the front end is a portlet applications using good old JSPs.

  1. Introduction and Scope
  2. High Level View
  3. Architecture Topics

General

  1. How to write a new portlet
  2. Adding a new backend service
  3. Changing the data model
  4. REST API overview
  5. Migrating to Javascript modules

Special

  1. Filtering in portlets
  2. The FOSSology integration
  3. How moderation requests work
  4. Roles and access rights
  5. Attachment Types Description
  6. Our ideas of Google-Summer-of-Code 2019
  7. How Friendly URLs work with the Liferay Portlets

Testing sw360

Generally, all modules have unit tests and these are executed (including deployment of couchdb) at CI times. In addtion, to test the front end, there are defined integration test cases for a manual check, if the sw360 is working properly in general:

  1. Test Cases: Components Functionality
  2. Test Cases: Licenses Functionality
  3. Test Cases: Moderations Functionality
  4. Test Cases: Projects Functionality

SW360 RESTful API

Test Cases

SW360 Assorted Test Cases

How to add a backend portlet to sw360

How to add a frontend portlet to sw360

SW360 Development Branches

Helps to see who is responsible and to which issue the Pull Request corresponds

How to add fields to an existing class

CouchDB External Documents

Database migration using Costco

Definition of Done

The definition of done helps to set a common understanding for solving a ticket.

Filtering in Portlets

Fossology Integration

Basis of communication between SW360 and FOSSology

Liferay Friendly

Basis of communication between SW360 and FOSSology

Moderation Requests

Release and Versioning

Our Versioning and Release Principles

Roles and Authorization

SW360 Roles and Authorization

Semantic Commits

Testing Frameworks

Behaviour testing

Troubleshooting

List of small issues / tips when developing for SW360

Using RequireJS fro Javascript Modules

Last modified January 16, 2023: upd(project): Minor updates (aac964c)