mirror of https://github.com/jlengrand/helidon.git synced 2026-03-10 08:21:17 +00:00

Files

Romain Grecourt fde8b42ed0 New media support API. (#1356 )

Rework media support API.
 - Fixes #820 
 - a few APIs are deprecated to be handled later with #1375 
 - building block for the upcoming HTTP client and Multipart media support

2020-02-11 10:52:19 -08:00

application-pom.md

Spec: overview of Helidon Application Poms (#1057 )

2019-09-26 11:39:40 -07:00

config-api.md

Config for Helidon 2.0 (#1102 )

2019-12-05 11:23:29 +00:00

context.md

Helidon common context OnePager. (#599 )

2019-05-04 20:50:06 +02:00

db.md

Helidon DB Client (#657 )

2020-01-23 18:42:21 +01:00

dockerbuild-local-snapshots.md

Application poms (#1022 )

2019-09-12 15:48:09 -07:00

generic-mapping.md

Helidon DB Client (#657 )

2020-01-23 18:42:21 +01:00

generic-type.md

Proposal for generic type mapping. (#204 )

2018-11-19 12:37:17 -08:00

protobuf.md

Protobuf support proposal (#280 )

2019-01-02 17:05:07 -08:00

README.md

Create a directory for specifications

2018-11-09 12:15:00 -08:00

README.md

Internal Documents and Specifications

This directory contains internal documents and specifications. These fall into a number of categories:

Guidelines and best practices
Design documents
Feature proposals
Or pretty much anything else

By keeping our documents as source code we can easily find them and easily review them.

Specs vs GitHub Issues

In many cases GitHub issues are sufficient for tracking requirements and basic proposals. But a spec might be more appropriate if you want an easy to review, living document with a fair amount of detail.

Use Markdown

Write your specs in Markdown. AsciiDoc is also OK if you need it.