Regaining the developer-quality-of-life benefits of H2

Confluence Development Confluence Data Center
#1

For a number of years, our internal dev process for working on Confluence Server / DC apps has relied on the built-in H2 database.

For us, the main benefits of developing against H2 were:

  1. Didn’t require each developer to provision or manage their own Postgres (or similar) instance or database
  2. The first-run experience in a clean environment (e.g. after running atlas-clean) was greatly simplified

We encourage our developers to regularly run atlas-clean, so any friction in the Confluence first-run experience has a noticeable impact on our productivity.

The built-in H2 database:

  • automatically applied a timebomb license for the host product
  • automatically included a default Confluence space
  • didn’t require a separate db process to be spawned alongside atlas-run
  • entirely skipped the setup wizard (where you are prompted to configure the DB connection, choose how users & groups are managed etc).

With Confluence 8 having now dropped support for H2, we have standardised on Postgres as our primary DBMS for development.

I have included below the relevant parts of our pom.xml that we added when switching from H2 to Postgres:

<build>
  <plugins>
    <plugin>
      <configuration>

        ...(other stuff)...

        <instanceId>instanceId1</instanceId>
        <products>
          <product>
            <id>confluence</id>
            <instanceId>instanceId1</instanceId>
            <version>${confluence.version}</version>
            <dataPath>src/main/resources/empty-home</dataPath>
            <dataSources>
              <dataSource>
                <jndi>jdbc/DefaultDS</jndi>
                <url>jdbc:postgresql://localhost:5432/confluence</url>
                <username>confluence</username>
                <password>confluence</password>
                <driver>org.postgresql.Driver</driver>
              </dataSource>
            </dataSources>
          </product>
        </products>
    </configuration>
</plugin>

Where possible, we are looking to reclaim some of the developer-quality-of-life features that H2 used to provide.

When starting from a clean environment, is it possible to automatically configure/apply (e.g. via pom.xml configuration):

  1. Our company’s Confluence DC test license for the host
  2. Our company’s DC test license for the app
  3. A default db configuration (connectstring etc.) - despite specifying a dataSource in our pom.xml, Confluence doesn’t seem to automatically use this on first run?
  4. A Confluence admin account
  5. Any other setup wizard choices (e.g. clustered vs non-clustered, how users & groups are managed etc.
  6. A default Confluence space

Our goal is to make it dead simple for any developer to run atlas-clean && atlas-run, and be up and running in a preconfigured Confluence dev environment with minimal effort, like H2 used to provide us.