This repository was archived by the owner on May 26, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on May 26, 2026. It is now read-only.
Refactor jtx Board access to separate layers for storage + mapping #117
Description
See also: https://github.com/bitfireAT/davx5/issues/670
We can use the new event architecture (at.bitfire.synctools.{icalendar,mapping.calendar,storage.calendar}) as a template.
Done when:
- JtxContract shouldn't use ical4j
- Storage, mapping and iCalendar access are separated
- No separate data class required
- DAVx5:
LocalJtxCollectionshould useJtxCollection(and not inherit from it) - Storage API is in
at.bitfire.synctools.storage.jtxboardpackage- Collection (similar to calendar): jtx Collection
- Are exceptions of recurring tasks supported? If yes, we need additional classes
- Item: jtx iCalendar object, stored in
Entitythat represents rows in jtx Board provider
- Mapping API is in
at.bitfire.synctools.mapping.jtxboardpackage - iCalendar API is in
at.bitfire.synctools.iCalendarpackage - All classes have proper tests
Activity
rfc2822 commentedon May 26, 2026
Moved to bitfireAT/davx5-ose#2265. We want to analyze the current state / goal again and then create the respective sub-issues in the new issue.