Split OTP into separate modules

[t2gran]

With everything in one module it is difficult and time-consuming to enforce the modularity. By breking OTP into modules it will be easier to understand where the boundaries are and they can be enforced in maven dependency - not manually.

This will also allow us to set different quality assurance requeierments for each model. We can for example only allow the core team of developers to change the most important part of the code.

This will also mak it possible to divide OTP into more then one runtime (process) later or swap out part of OTP. There has been a few request for using other street routers - this is probably a difficult task, but should be easier if there is a clear boundary around the street routing. For example, the internal state of AStar is today leaked outside of AStar when returning the result.

A good starting point would be:

• otp-lang -- Common set of scalars and utility methods
• application -- OTP Main, configuration(otp/build/router), putting it together - avoid business logic here.
• raptor -- Raptor implementation
• transit -- With sub-modules (packages) for site, network and timetable. In addition there should be services for query and updating data. Support for applying real-time updates should be here.
• street-graph -- AStar and the street graph implementation
• graph-builder -- static data import, sub modules for osm, elevation, netex, gtfs ++
• sandbox -- Today there is not a clear boarder between the sandbox modules and the core. There are dependencies going both ways - this would need to be fixed.
• updaters
• apis

This overview is incomplete, the details must be worked when doing this.

Here is an overveiew of what I think could be the target:

[t2gran]

I have now ported most of the suggestions in PR #6130, but a few things reminds:

• I dropped the modules directory - most of the directories at root level are modules - not all are Java/maven modules, but still. I do not see a reason to group the Java Maven modules under modules.
• Plugins need to be put in plugin management and reorganized in the modules - not all plugins apply to all modules.
• Apply useful Maven plugins (See build: Moving OTP to its own Maven module, refactor out Raptor into its own module #6130)
• Start using Java Modules
• Split out Sandbox modules - this need a bit of analyzis to se what other modules we need to split out as well to get it to work. The application, wiring everything together, need to know about the Sandbox, and the Sandbox probably need to know about the OTP domain model ++.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days