Where Is the OpenMetadata Source Code Located? Complete Repository Guide

The OpenMetadata source code is located at github.com/open-metadata/OpenMetadata, a single monorepo containing Java, Python, TypeScript, and Go modules organized under distinct top-level directories.

This guide maps the complete OpenMetadata repository structure, showing you exactly where to find backend services, the React UI, Python ingestion connectors, and multi-language SDKs. Whether you're contributing code, debugging issues, or building custom integrations, understanding this layout is essential for navigating the 1,000,000+ lines of open-source metadata management code.

---

Repository Location and Organization

Primary GitHub Repository

All OpenMetadata source code lives in one place:

https://github.com/open-metadata/OpenMetadata

This monorepo approach keeps backend APIs, frontend components, ingestion frameworks, and client SDKs version-synchronized. When you clone this repository, you get complete cross-stack source code for building, testing, and deploying the entire OpenMetadata platform.

---

Top-Level Module Structure

The repository root contains eight primary modules, each with dedicated source directories:

Module	Technology Stack	Primary Source Path
Backend Services	Java 21 + Dropwizard	openmetadata-service/src/main/java/
Web UI	React + TypeScript	openmetadata-ui/src/main/resources/ui/src/
Ingestion Framework	Python 3.10-3.12	ingestion/src/main/python/
OpenMetadata Clients	Java, Python, Go	openmetadata-clients/
Common Utilities & Schemas	JSON Schema, Java, Python	openmetadata-spec/
Integration Tests	JUnit, pytest	openmetadata-integration-tests/
Docker & Deployment	Bash, Python	docker/, scripts/

---

Backend Services Source Code (Java)

Core Service Implementation

The Java backend powers REST APIs, authentication, metadata storage, and event processing. Source files are organized under:

openmetadata-service/src/main/java/org/openmetadata/service/

Key subdirectories include:

• resources/ — REST resource classes exposing API endpoints
• jdbi3/ — Data access objects and database interaction layer
• security/ — Authentication and authorization implementations
• events/ — Event publishing and webhook handling

Entity Resources Example

In openmetadata-service/src/main/java/org/openmetadata/service/resources/entities/table/TableResource.java, the TableResource class defines CRUD operations for table metadata:

import org.openmetadata.service.resources.CollectionDAO;
import org.openmetadata.service.resources.entities.table.TableResource;

public Table getTableByFqn(String fqn) {
    CollectionDAO dao = new CollectionDAO();
    return dao.tableDAO().findByName(fqn);
}

Schema and Model Definitions

Database entities and JSON-serializable models reside in:

openmetadata-service/src/main/java/org/openmetadata/schema/

This package contains auto-generated classes derived from canonical JSON schemas, ensuring type consistency across backend and ingestion components.

---

Web UI Source Code (TypeScript/React)

Frontend Application Structure

The React-based user interface source resides at:

openmetadata-ui/src/main/resources/ui/src/

This directory contains:

Subdirectory	Purpose
components/	Reusable UI components (tables, forms, lineage graphs)
pages/	Top-level route components
utils/	Helper functions and API clients
generated/	TypeScript types from JSON schemas

API Integration Example

In openmetadata-ui/src/main/resources/ui/src/utils/rest-utils.ts, REST utilities handle server communication:

import { getList } from 'rest-utils';
import { Service } from 'generated/services';

const fetchServices = async (): Promise<Service[]> => {
  const response = await getList('/api/v1/services');
  return response.data as Service[];
};

Build Configuration

The UI build system uses:

• Yarn for package management — openmetadata-ui/package.json
• Vite for development server and production builds
• TypeScript with strict configuration for type safety

---

Ingestion Framework Source Code (Python)

Connector and Pipeline Implementation

The Python ingestion framework extracts metadata from external systems. Source code is located at:

ingestion/src/main/python/

Primary packages include:

Package	Path	Purpose
metadata.ingestion.source	.../metadata/ingestion/source/	Database and service connectors
metadata.ingestion.pipeline	.../metadata/ingestion/pipeline/	Ingestion workflow definitions
metadata.generated	.../metadata/generated/	Pydantic models from JSON schemas

Custom Connector Example

In ingestion/src/main/python/metadata/ingestion/source/database/mysql/connection.py, connection handling for MySQL sources:

from metadata.ingestion.source.database import DatabaseSource
from metadata.ingestion.models.table import Table

class MySQLSource(DatabaseSource):
    def get_tables(self) -> Iterable[Table]:
        # Custom logic to retrieve tables from MySQL

        ...

Packaging and Dependencies

The ingestion framework uses Poetry for dependency management:

• Configuration: ingestion/pyproject.toml
• Lock file: ingestion/poetry.lock

This supports Python versions 3.10 through 3.12 with Pydantic v2 for data validation.

---

Client SDKs and Specifications

Multi-Language Clients

OpenMetadata provides official client libraries in multiple languages under:

openmetadata-clients/

Current implementations include:

Language	Path
Java client	openmetadata-clients/openmetadata-java-client/
Python client	openmetadata-clients/openmetadata-python-client/
Go client	openmetadata-clients/openmetadata-go-client/

Go Client Example

package main

import (
    "context"
    "github.com/open-metadata/openmetadata-client-go"
)

func listTables() {
    client := openmetadata.NewClient("http://localhost:8585/api")
    tables, _ := client.Table.GetAll(context.Background())
    fmt.Println(tables)
}

Canonical Schema Specifications

The openmetadata-spec/ directory contains JSON Schema files that serve as the single source of truth for:

• Entity definitions (tables, topics, dashboards, pipelines)
• API request/response contracts
• Type definitions for code generation

These schemas drive Pydantic model generation for Python and TypeScript type generation for the UI, ensuring cross-stack consistency.

---

Build System and Configuration Files

Root-Level Build Orchestration

The repository root contains configuration files that coordinate multi-language builds:

File	Purpose
pom.xml	Maven configuration for Java backend and service modules
Makefile	Common development tasks (format, test, build)
.github/workflows/	CI/CD pipelines for testing and releases

Module-Specific Configuration

Key configuration files by module:

Backend services:

• openmetadata-service/pom.xml — Service-specific dependencies
• conf/openmetadata.yaml — Runtime configuration (database, auth, logging)

Web UI:

• openmetadata-ui/package.json — Node dependencies and scripts
• openmetadata-ui/vite.config.ts — Build tool configuration

Ingestion framework:

• ingestion/pyproject.toml — Poetry packaging and Python dependencies

Docker and Deployment

Deployment artifacts are located in:

docker/

This directory contains:

• openmetadata/db/ — PostgreSQL and MySQL database images
• openmetadata/server/ — Backend service container
• openmetadata/ingestion/ — Pipeline executor images
• docker-compose.yml — Local development stack

---

Testing and Integration

Test Suite Locations

The OpenMetadata repository maintains comprehensive tests across all modules:

Test Type	Location	Framework
Unit tests (Java)	openmetadata-service/src/test/java/	JUnit 5
Integration tests (Java)	openmetadata-integration-tests/	TestContainers
UI component tests	openmetadata-ui/src/test/	Jest + React Testing Library
Python ingestion tests	ingestion/tests/	pytest
Connector integration tests	ingestion/tests/integration/	pytest + Docker

CI/CD Validation Scripts

Utility scripts in scripts/ support automated quality checks:

• scripts/validate_yaml.py — Schema validation for configuration files
• scripts/generate-openapi-spec.sh — OpenAPI documentation generation
• scripts/run_local.sh — Local development environment bootstrap

---

Summary

• Primary repository: github.com/open-metadata/OpenMetadata — single monorepo containing all source code
• Java backend: openmetadata-service/src/main/java/ — Dropwizard-based REST API and metadata services
• React UI: openmetadata-ui/src/main/resources/ui/src/ — TypeScript frontend with MUI components
• Python ingestion: ingestion/src/main/python/ — connector framework for metadata extraction
• Client SDKs: openmetadata-clients/ — Java, Python, and Go programmatic interfaces
• Canonical schemas: openmetadata-spec/ — JSON Schema definitions driving cross-stack code generation

---

Frequently Asked Questions

Where is the main OpenMetadata GitHub repository hosted?

The official repository is hosted at github.com/open-metadata/OpenMetadata. This single repository contains all backend services, frontend code, ingestion connectors, client SDKs, and deployment configurations in a unified monorepo structure.

What programming languages are used in the OpenMetadata source code?

OpenMetadata uses four primary languages: Java 21 for the backend services, TypeScript/React for the web UI, Python 3.10-3.12 for the ingestion framework, and Go for one of the client SDKs. The repository also contains JSON Schema definitions that generate type-safe code across all language stacks.

Where can I find the OpenMetadata Python ingestion connectors?

The Python ingestion framework and all connector implementations are located in ingestion/src/main/python/. Specific database connectors reside in metadata/ingestion/source/database/, with each service (MySQL, PostgreSQL, Snowflake, etc.) having its own subdirectory containing connection, metadata extraction, and lineage logic.

How do I build and run OpenMetadata from source?

To build from source, clone the repository and use Maven for Java components (mvn clean install), Yarn for the UI (yarn install && yarn build), and Poetry for Python ingestion (poetry install). The docker/ directory provides docker-compose.yml for running the complete stack locally without manual builds.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}