Development
Developing sw360
The sw360 is Java-based application consisting of two main parts:
- A Liferay/based front end application that allows users to work with sw360
- A Java-based servlet infrastructure Thrift interfaces that allows the Liferay part and other applications to manage and store data
- 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:
- https://issues.apache.org/bugwritinghelp.html
- https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines
- https://www.joelonsoftware.com/2000/11/08/painless-bug-tracking/
Contribution Workflow
As basic introduction, the dev ops works as following:
- We are issue-based, please do not hesitate to create issues - also for questions (and set the issue tag)
- The issues are organised by milestones which do not represent releases anymore. Milestone are meant to be useful packages of work done
- Contributions are made through pull requests
- We do conversations directly on issues and pull requests
More topics regarding “how” to develop:
- Definition of done and code style
- Creating a sw360 release
- Brief notes on the jgiven testing
- 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.
General
- How to write a new portlet
- Adding a new backend service
- Changing the data model
- REST API overview
- Migrating to Javascript modules
Special
- Filtering in portlets
- The FOSSology integration
- How moderation requests work
- Roles and access rights
- Attachment Types Description
- Our ideas of Google-Summer-of-Code 2019
- 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:
- Test Cases: Components Functionality
- Test Cases: Licenses Functionality
- Test Cases: Moderations Functionality
- Test Cases: Projects Functionality
Test Cases
SW360 Assorted Test Cases
SW360 Development Branches
Helps to see who is responsible and to which issue the Pull Request corresponds
Definition of Done
The definition of done helps to set a common understanding for solving a ticket.
Fossology Integration
Basis of communication between SW360 and FOSSology
Liferay Friendly
Basis of communication between SW360 and FOSSology
Release and Versioning
Our Versioning and Release Principles
Roles and Authorization
SW360 Roles and Authorization
Testing Frameworks
Behaviour testing
Troubleshooting
List of small issues / tips when developing for SW360