Complete monorepo implementation of the NAESB Energy Services Provider Interface (ESPI) 4.0 specification for Green Button energy data standards.
# Clone the monorepo
git clone https://github.com/GreenButtonAlliance/OpenESPI-GreenButton-Java.git
cd OpenESPI-GreenButton-Java
# Build all modules (Java 21 + Jakarta EE throughout)
mvn clean install
# Run Spring Boot 3.5 modules
cd openespi-datacustodian && mvn spring-boot:run
cd openespi-authserver && mvn spring-boot:run| Module | Description | Java | Jakarta EE | Spring Boot | Status |
|---|---|---|---|---|---|
| openespi-common | Shared domain models, services | 21 β | 9+ β | 3.5.0 β | Production |
| openespi-datacustodian | OAuth2 resource server | 21 β | 9+ β | 3.5.0 β | Production |
| openespi-authserver | OAuth2 authorization server | 21 β | 9+ β | 3.5.0 β | Production |
| openespi-thirdparty | Client application | 21 β | 9+ β | 4.0.6 |
Partial Migration |
βββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββ
β Third Party βββββΆβ Authorization βββββΆβ Data Custodian β
β (Java 21+Jakarta)β β Server (SB 3.5) β β Server (SB 3.5) β
β β β (Independent) β β β
βββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββ
β β
β β
ββββββββββββββββββββββββββββββββββββββββββββββββ
βΌ
βββββββββββββββββββ
β OpenESPI Common β
β (Spring Boot 3.5)β
βββββββββββββββββββ
Module Dependencies:
- openespi-common: Foundation library (no dependencies on other modules)
- openespi-datacustodian: Depends on openespi-common
- openespi-authserver: Independent (no dependency on openespi-common)
- openespi-thirdparty: Depends on openespi-common
All modules now support:
- β Java 21 - Modern JVM with performance improvements
- β Jakarta EE 9+ - Modern enterprise Java APIs
- β Consistent build system - Maven 3.9+ throughout
Spring Boot 3.5 modules:
- β openespi-common - Foundation library
- β openespi-datacustodian - Resource server
- β openespi-authserver - Authorization server
Partially migrated:
β οΈ openespi-thirdparty - Java 21 + Jakarta ready, Spring Boot migration in progress
# Build everything - all modules are Java 21 compatible
mvn clean install
# Test specific module
mvn test -pl openespi-datacustodian -am# Build only fully-migrated modules
mvn clean install -Pspring-boot-only# Work on Common module
cd openespi-common
mvn clean test
mvn spring-boot:run
# Work on DataCustodian
cd openespi-datacustodian
mvn clean test -am # Test with dependencies
mvn spring-boot:run
# Work on AuthServer
cd openespi-authserver
mvn clean test -am
mvn spring-boot:runThe ThirdParty module preserves important migration work from the main branch:
β Completed (from main branch):
- Java 1.7 β Java 21 upgrade
- javax.servlet β jakarta.servlet migration
- JSP/JSTL Jakarta compatibility
- Modern Maven toolchain
π Next Steps:
- Spring Framework β Spring Boot 3.5 migration
- OAuth2 client modernization
- Configuration externalization
# Test all modules
mvn test
# Test specific module
mvn test -pl openespi-commonPrerequisites:
- Docker Desktop installed and running
- Minimum 4GB RAM allocated to Docker
- Ports 3306 (MySQL) and 5432 (PostgreSQL) available
Quick Start:
# Verify Docker is running
docker --version && docker ps
# Run all integration tests (H2, MySQL, PostgreSQL)
mvn verify -pl openespi-common -Pintegration-tests
# Run specific database tests
mvn test -Dtest=ComplexRelationshipMySQLIntegrationTest -pl openespi-common
mvn test -Dtest=ComplexRelationshipPostgreSQLIntegrationTest -pl openespi-common
# Cross-module integration
mvn verify -Pfull-integrationWhat Gets Tested:
- β H2: In-memory database with vendor-neutral migrations
- β MySQL 8.0: TestContainers with BLOB column types
- β PostgreSQL 15: TestContainers with BYTEA column types
- β Flyway Migrations: Vendor-specific migration paths
- β JPA Relationships: Complex entity hierarchies
- β Transaction Boundaries: Data consistency across transactions
- β Bulk Operations: saveAll, deleteAll operations
TestContainers Configuration:
- MySQL container:
mysql:8.0 - PostgreSQL container:
postgres:15-alpine - Container reuse enabled for faster test execution
- Automatic cleanup after tests complete
Troubleshooting:
# If containers fail to start
docker system prune # Clean up Docker cache
docker pull mysql:8.0
docker pull postgres:15-alpine
# View running containers during tests
docker ps
# Check container logs
docker logs <container_id>The project uses Flyway with a vendor-specific migration strategy to support H2, MySQL, and PostgreSQL:
openespi-common/src/main/resources/db/
βββ migration/
β βββ V1__Create_Base_Tables.sql # Vendor-neutral base tables
β βββ V3__Create_additiional_Base_Tables.sql # Additional shared tables
βββ vendor/
βββ h2/ # (Future: H2-specific migrations)
βββ mysql/ # (Future: MySQL-specific migrations)
βββ postgres/ # (Future: PostgreSQL-specific migrations)
Current Implementation:
- All migrations are currently in the base
db/migrationdirectory - Tables use vendor-neutral SQL syntax compatible with all three databases
- Future enhancements will move vendor-specific tables to
/vendor/{database}/paths
Migration Locations by Profile:
test(H2):classpath:db/migrationtest-mysql:classpath:db/migration,classpath:db/vendor/mysqltest-postgresql:classpath:db/migration,classpath:db/vendor/postgresdev-mysql:classpath:db/migration,classpath:db/vendor/mysqldev-postgresql:classpath:db/migration,classpath:db/vendor/postgres
Vendor-Specific Column Types:
| Type | H2 | MySQL | PostgreSQL |
|---|---|---|---|
| Binary Data | BINARY |
BLOB |
BYTEA |
| UUID | UUID |
CHAR(36) |
UUID |
| Timestamps | TIMESTAMP |
DATETIME |
TIMESTAMP |
Running Migrations:
# Migrations run automatically on application startup
mvn spring-boot:run
# Test migrations with specific database
mvn test -Dtest=ComplexRelationshipMySQLIntegrationTest
mvn test -Dtest=ComplexRelationshipPostgreSQLIntegrationTest
# Validate migration status
mvn flyway:info -pl openespi-commonEach module has independent deployment capabilities:
- Common: Maven Central library (shared dependency)
- DataCustodian: Kubernetes/Docker deployment (Spring Boot 3.5 JAR)
- AuthServer: Kubernetes/Docker deployment (Spring Boot 3.5 JAR)
- ThirdParty: WAR deployment to Tomcat/Jetty
β οΈ Temporary - awaiting Spring Boot 3.5 migration for containerization
Note on ThirdParty Deployment: ThirdParty currently uses legacy WAR packaging because it runs on Spring Framework (not Spring Boot) with JSP/JSTL views. Once the Spring Boot 3.5 migration completes, it will switch to executable JAR packaging with embedded server and Docker/Kubernetes deployment like the other modules.
# Build individual service images
cd openespi-datacustodian && docker build -t openespi-datacustodian .
cd openespi-authserver && docker build -t openespi-authserver .# Deploy with Helm
helm install openespi-datacustodian ./helm/datacustodian
helm install openespi-authserver ./helm/authserverThis monorepo was created by consolidating separate repositories:
- openespi-common: From OpenESPI-Common-java (main branch)
- openespi-datacustodian: From OpenESPI-DataCustodian-java (main branch)
- openespi-authserver: From OpenESPI-AuthorizationServer-java (main branch)
- openespi-thirdparty: From OpenESPI-ThirdParty-java (main branch)
All original commit history has been preserved using git subtree.
- Migration Status - Detailed migration information
- Development Guide - Development workflow
- Deployment Guide - Production deployment
- API Documentation - REST API reference
- Fork the repository
- Create a feature branch (
git checkout -b feature/amazing-feature) - Make your changes in the appropriate module
- Test your changes (
mvn test -pl <module> -am) - Commit your changes (
git commit -m 'Add amazing feature') - Push to the branch (
git push origin feature/amazing-feature) - Open a Pull Request
- Follow existing code style in each module
- Write tests for new functionality
- Update documentation as needed
- Ensure CI/CD pipelines pass
Licensed under the Apache License 2.0. See LICENSE for details.
- Green Button Alliance: https://www.greenbuttonalliance.org
- Issues: https://github.com/GreenButtonAlliance/OpenESPI-GreenButton-Java/issues
- Discussions: https://github.com/GreenButtonAlliance/OpenESPI-GreenButton-Java/discussions
Migration Strategy: All modules use main branches to preserve maximum migration work and ensure Java 21 + Jakarta EE consistency across the ecosystem.
Built with β€οΈ by the Green Button Alliance community