Long term KC related code maintenance plan

Problem/Motivation

The plan has been to maintain as low amount of KC related code as possible, but some bits needed custom adjustments for compatibility.

Relevant lines from #23 (comment 1824115764)

For the long term, on code that will be maintained after the migration, there may be a few things to think about. Namely compatibility with KC, and dependencies updates.

Following a summary of those criteria for each codebase.

• drupal-theme
  • No Java dependencies.
  • Depends on mix for asset building, on top of Node.js 20.x. Mostly it does not really need to be kept up-to-date, since it is about the assets, not really running code.
  • Needs to be compatible with KC version in use.
• drupalorg-user-migration
  • Does not need maintenance after final user data import.
• keycloak-realm-configuration
  • A simple way to track changes on KC instance configuration, currently manual exports from KC UI, nothing automated.
• php-pass-provider
  • Needs to be maintained at least until the last user has changed its old password. Maybe a deadline could be set to enforce the transition and stop adding/maintaining this extension.
  • Needs to be compatible with KC version in use.
  • Java dependencies, on maven repository: keycloak-core, keycloak-server-spi-private, keycloak-server-spi, jboss-logging, junit-jupiter-api, junit-vintage-engine, easymock
  • Java dependency not on maven repository, in theory at Mollom/phpass-java (404), but actually used git hash version found at spharion88/phpass-java.

    <dependency>
      <groupId>com.github.Mollom</groupId>
      <artifactId>phpass-java</artifactId>
      <version>d2dd590</version>
    </dependency>

Proposed resolution

Let us try to draft a plan on how all those dependencies will be maintained over time.

Notes

Started at #23 (closed).