Hi @jrichards
I don’t think it’s that issue. It’s some other issue that kicks in when the migration agent tries to run migrations on H2-database so it’s not related to quick-reload. When starting Confluence Server and migration agent tries to run migrations, I get lots and lots of errors executing SQL for the migrations.
I’ve written about this issue before: Database migrations fail to run on Server 7.15.0 when starting in dev-mode and there is this ticket that describes the problem: [CONFSERVER-60949] Confluence 7.11 EAP development instance keeps throwing "Failed to update database schema" caused by migration assistant app - Create and track feature requests for Atlassian products.
So for I’ve disabled the migration-agent to get around this but the problem is that when I now start Confluence Server, I need to update to new CCMA in order to test if MIG-905 is actually fixed as it claims in a comment for the ticket and it seems that the new updated CCMA version is expecting some database changes and wants to run the migration agent, but of course it won’t run because I’ve disabled it and thus CCMA fails to initialise with all sorts of SQL errors (column not found etc).
So I would need to have either
- Migrations with H2 working as expected
- Use external database where migrations seem to work as this is a H2-specific problem
Either one of those would help me to finally proceed with the server-cloud migration implementation and especially verifying if the space-restriction issue would be finally fixed. But unfortunately now I’m unable to proceed.
EDIT: So this has been my workaround so far: -Datlassian.plugins.startup.options=disable-addons=com.atlassian.migration.agent but with the new CCMA version that is not working anymore.
EDIT2: I don’t need quick-reload because JRebel (a product from our company) works fine with confluence server in development as it will hot-reload any code changes into running JVM so I can modify the plugin and have the code reloaded almost immediately into the running JVM.