SW360

Mentors: Student: Sandyp

SW360 currently imports license and obligation data through five disconnected paths with no coordination between them, meaning multiple instances can hold different obligation text for the same license with no way to detect the gap. This project makes LicenseDB the single authoritative source by implementing scheduled REST based synchronization. It covers paginated license and obligation sync, incremental daily updates via the audit log, field-level mapping that preserves SW360-specific compliance fields, read-only gating of legacy import paths, and CouchDB-first lookup for CLI attachment processing. Deliverables include JWT authentication, automated daily scheduling via ScheduleHandler, admin REST endpoints for sync control and health monitoring, encrypted credentials, circuit breaker and rate limiting, a migration guide, and test coverage.

Mentors: Student: Taanvi Khevaria

SW360 instances running for years accumulate thousands of stale projects, components, and releases that slow down searches, waste disk space, and clutter the UI. Currently, the only cleanup option is permanent deletion with no undo. This project adds a reversible archival workflow. Admins select entities, export them as self-contained TAR.GZ bundles with all metadata and attachments, then remove them from the live database. A CouchDB registry tracks what was archived and by whom. To restore, admins upload the archive, preview contents with conflict detection, and selectively re-insert entities. Deliverables: archival.thrift service definition, backend Maven module with archive and restore logic, REST API endpoints, a frontend admin page with entity selection, registry table, and multi-step restore flow, plus unit and E2E tests."

Mentors: Student: Shivamrut

SW360 today uses Apache Thrift for backend-to-backend calls. That choice forces a Thrift toolchain and many .thrift IDLs, ships large WARs via shared Thrift servlet code, makes traffic hard to debug with normal HTTP tools, and limits standard metrics and load testing. Project goal is to migrate the backend incrementally to Spring Boot REST with a shared libraries/service-api contract (plain POJOs instead of generated Thrift types), WebClient from the resource-server, and a Converter pattern where backend-common still uses Thrift-shaped DB types, so each service can move without a big-bang rewrite. Health and Vendor are already implemented as proof of concept with benchmarks and parity checks. Deliverables: migrate all 23 Thrift-backed service clients, shrink/remove Thrift from the build, delete or retire IDLs and ThriftClients factory methods as each service lands, document the migration recipe and architecture tradeoffs (including optional gRPC for hot paths if mentors agree), keep the public REST/HATEOAS API stable for consumers, and finish with full-system tests, updated contributor docs, and final benchmarks. Work is phased by dependency tiers (standalone services first, Schedule and final cleanup last) on GSoC 2026’s extended coding period, with buffers for review and integration risk.

Mentors: Student: Rohit Borra

This proposal aims to improve the testing framework for SW360’s REST API endpoints by addressing limited test coverage, insufficient integration tests, and outdated testing workflows. The project will focus on writing comprehensive unit tests for CRUD operations and edge cases, developing integration tests for multi-endpoint workflows, and creating reusable utilities for database mocking and error simulation. Additionally, CI/CD pipelines will be automated with tools like JaCoCo for test coverage tracking and regression prevention. Deliverables include a robust test suite, enhanced testing infrastructure, automated pipelines, and detailed documentation to simplify onboarding and contributions. These improvements will make SW360's APIs more reliable, scalable, and maintainable for the developer community.

Mentors: Student: Ritankar Saha

Currently, SW360’s integration with FOSSology is limited to only basic functionalities using outdated endpoints namely, triggering scans and checking scan status. This results in inefficient workflows, redundant uploads, lack of flexibility in scanning configurations, and restricted report formats. It also misses opportunities for reuse of scan data and lacks user-level attribution and secure token handling. This project and proposal aims to refactor and extend SW360's FOSSology integration by utilizing the modern RESTful API (OpenAPI v2 spec) offered by FOSSology. It will enable advanced functionalities such as: 1. Direct Source Uploads via POST /uploads 2. Checksum-Based Search and Reuse using /filesearch 3. Selectable Scanning Agents (e.g., Nomos, Monk, Reuser) 4. Multi-Format Report Generation (SPDX, CycloneDX, etc.) 5. User-Specific Token Support for secure and auditable API interactions These enhancements will be implemented through a modular, secure, and scalable API integration layer in SW360, with robust error handling, polling mechanisms, and extensibility for future API versions. Deliverables: 1. REST API Refactoring of SW360's FOSSology connector using modern v2 endpoints. 2. Efficient File Upload System with token-based authentication and job initiation. 3. Checksum Reuse Logic to avoid duplicate scans and utilize FOSSology’s “Reuser” agent. 4. Configurable Scanning Agent Support exposed via backend APIs. 5. Support for Diverse Report Formats, download mechanisms, and metadata linking. 6. Secure Token Management for both server-wide and user-specific workflows. 7. Robust Error Handling, retry logic, audit logging, and performance tuning. 8. Comprehensive Testing, documentation, and CI/CD pipeline integration.