[sw360-dev] F2F Meeting in Munich on June 4th: what was worked on

["Michael C. Jaeger" <mcj@xxxxxx>]

Hi,

I am sorry I did not manage to finish the minutes form the last in person meeting on June 4th in Munich before my vacation.

Please find them below. To those who did not attend the in-person meeting: please feel encouraged to continue a discussion on this list.

Kind regards, Michael


----

Notes on the SW360 F2F meeting, June 4th

Attending (in seating order): Nutan, Smruti, Michael (me), Markus, Leo, Maximilian, Kalle, Andi

Location: Siemens Neu Perlach Sued, Building 33, Room 33.443

Schedule: 10:00 Start until 17:00, 17:30 Beergarden https://kleines-brauhaus-dickermann.de

## Topics

* Data Model
* Releasing and Pull Request Situation
* Migrating to LF 7.1
* Attachments and Thrift
* SW360 Deployment
* sw360antenna integrated to sw360 build

## Data Model

* Presenting the Bosch OSMI Datamodel general considerations
* Amoung other points, new:
 * Coordinates, such as package manager info
 * Software Heritage link, and id
 * List of known binary hashes
 * Data quality information
 * Automatically getting out info of attachments
* Discussion about pro and con of automatically pulling data from sources
* Discussion of the data mode: add more flexibility to sw360 is required
* point is that many attributes are rather specific to orgs, therefore flexibility would be good improvement in sw360.

* Summary, what is required:
 * Take existing data objects and look if they are core data fields and extensible attributes
 * We should have a core model, better: core attributes  for every document
 * discussion if there are keys used for typing, but actually it is not same as data type
 * TODO Michael make a wiki which defines core attributes
 * TODO Maximilian do a proof how to represent generic data types via Thrift
 * TODO all at each biweekly meeting review one data type item (like thrift object)
 * Validation rules should be there as new feature

* Sugestion is to make external Id click-able
 * for example, click on software heritage link.

## Releasing and Pull Request Situation

* TODO Michael create ticket for "what happens with moderation requests when using the moderation requests"? (referring to problem how it is actually handled using the REST API)
* Discussing a failure case after deployment even using testing on a staging system: Conclusion is there is no quick win for getting to a guaranteedly working build in which all necessary tests have been executed so that one don't need manual tests on top of code reviews before merging
* Categories in github for pull requests like "backend only", "frontend only" ... would help for coordination, make opportunities for work transparent
* TODO Michael lets have a project on github bringing more clarity ot the review situation: "preparing", "Ready for review", "in review", "ready for testing", "in testing", "ready for merge", "merged".
* Conclusion on the releasing is to still approach the eclipse project process for releasing.

## Lunch

* at 1230 meeting starting at 1330

## Migrating to LF 7.1

* Demo: overall impression: big imrovement in look and feel
* Liferay switched completely to a OSGi model
* Portlet project is now an OSGi bundle (not a war anymore)
* Theme was about to be deleted, but some styling stuff required (sass processor preprocessing, then css code for colouring all elements)
* Note that themes are Liferay specific and will result in a dedicated artefact still
* Right now no solution found (except for scripting the Web UI of course) for automating *.lar file import (which makes separate manual step at deployment still necessary)

#### Dependencies and Libraries

* actually, OSGi introduces a different way of handling dependencies now
* lib-datahandler is a now a OSGi bundle
* also the export lib (used for spreadsheet export is a OSGi bundle) and other two lib projects are separate OSGi bundles.
* Important to know for development: *.bnd files are hand written (it is the declaration!!!) for now. Maybe there are tools, but this rewrite they were just created by manual engineering
* There are dynamic components
* Liferay always ships jquery and boostrap 4
* see URL: https://test.sw360.lepokle.de:8443/
* users are like admin@xxxxxxxxx

#### Finalize the layout for other tabs

* full regression tests then
* rebase is maybe not difficult in between, so normal master can evolve still
* then after regeression testing merge
* also there is a branch on sw360chores already
* bascially, it is "only" about having the new container installed: https://www.liferay.com/downloads-community

#### How to deploy the *.lar file(s)

* When logged in with appropriate rights, o to the left menu
* select the sw360 main section
* go into subsection "publishing"
* select Import
* and the in import go to the plus sign
* Continue
* select "public" or "private"
* theme settings, ..., site page, keep checked, first import could delete missing pages
* Import permissions set to  yes
* check "mirror with overwriting"
* use the "current user as author"
* hit import

## Attachments and Thrift

* Situation: curently the attachments data upload is inconsistent, bypassing the thrift API because thrift does not support streams
* Rather the uploads are passed directly to couchdb (from Portlet) with a portlet facade to couchdb and another facade for REST API
* Both implementation should be unify implementation
* Move it out thrift in general or to one common place? (attachment metadata is covered by thrift)

## SW360 Deployment

* some works on splitting the deployment done: rest, backend, liferay
* including authentication for the thrift
* issue that there is no "general" authorization server - right now there is this way based on the liferay REST api or the custom keycloak integration for now
* there is a longer discussion if the keycloak should be part of the general stack of sw360
* conclusion is that to split the deployment first and then maybe see if there it makes sense to split the repo
* TODO Michael create issue to take over the antenna build script for versioning based on number of commit since tagged release (topic "releasing")

## sw360antenna integrated to sw360 build

* first test it locally to get better understanding.
* first test would to pick on project (maybe lib datahandler)
* What is required?
 * Maven deendency tree: there
 * License information can be get from maven central
 * then a first listing can be genrated.