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

Files

Romain Grecourt 0f6403374f Application poms (#1022 )

Create a new parent pom hierarchy to fit new applications-pom
Updated all examples to use the new application-poms
Normalized examples README.md
Updated examples Dockerfile to multi-stage
Remove dependency management for microprofile-metrics-api and leverage the transitive dependencies of helidon-metrics and helidon-metrics2.

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

config-api.md

Updates according to findings when refactoring.

2018-12-17 20:58:59 +01:00

context.md

Helidon common context OnePager. (#599 )

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

dockerbuild-local-snapshots.md

Application poms (#1022 )

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

generic-type.md

Proposal for generic type mapping. (#204 )

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

multipart.md

Update multipart proposal to fix a mistake in the buffered model. (#250 )

2018-12-10 16:33:13 -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.