~saiko/origami

a3bf2d41b05e8f17411550b5520bc7e476a10a0d — therealfarfetchd 1 year, 4 days ago d6bf094 master
Add designdoc.md
1 files changed, 44 insertions(+), 0 deletions(-)

A designdoc.md
A designdoc.md => designdoc.md +44 -0
@@ 0,0 1,44 @@
# General design

 - 2-stage loading: One program written in a native language (C/C++ or Rust, probably) that collects all required plugins, etc. and one written in Java that does the actual build. That way we don't have to wait 3 years like we have to for Gradle/the JVM to start up just to do a simple `gradle --version` (or other actions that are supposed to be relatively fast)
 - No code in the main build definition file. That's data only, such as dependency pipelines, or library version information.
 - Additional required build code can be either supplied by including a plugin 
 - package version lock system (like Cargo or npm). Dependencies specified in the file are only constraints, not actual versions: specifying version `1` will take any version that is 1.x: `1.0.0`, `1.4.2`, `1.5-rc3`. The latest of these which is also compatible with all other specified dependencies will be selected and saved in the package lock file, which keeps the package version used constant until a `origami update` is issued.
 - Providing build constants to Java code in a generated class file. This gets rid of ugly build time string replacements in source files.

# Dependency pipelines

Example:

    [dependencies]
    impl        maven 'dev.therealfarfetchd:some-library:1.0.0'
    impl mod    maven 'dev.therealfarfetchd:some-mod:1.0.0'
    (api|pack)  maven 'some.external.lib:lib:1.0.0'
    impl        local './libs/ancient-library-thats-not-on-maven.jar'

_(Syntax not final.)_

Dependencies are pulled in through pipelines. This is first of all data only, no 'configurations' or similar as in Gradle. There's a consumer part of the pipeline, which has to come first on each line (in this case, `impl`, `api` or `pack`). This actually does something with the dependency like adding it to the project.

The following segments of the pipeline transform the next segment, for example `mod` deobfuscates the library given to it.

Finally, there's a source part of the pipeline, which is the last one. This is the one that actually provides an artifact, `maven` for example pulls an artifact from one of the registered maven servers. Additional data like source archives are supported.

Pipeline segments can be joined with `(segment1|segment2|...)`. This will effectively expand to all the possible permutations of the line. For example,

    (impl mod|pack) (local './libs/a.jar'
                    |local './libs/b.jar'
                    |maven 'dev.therealfarfetchd:dep-mod:1')

is a valid pipeline, which expands to this:

    impl mod local './libs/a.jar'
    impl mod local './libs/b.jar'
    impl mod maven 'dev.therealfarfetchd:dep-mod:1'
    pack local './libs/a.jar'
    pack local './libs/b.jar'
    pack maven 'dev.therealfarfetchd:dep-mod:1'

Pipeline expansions can be nested. The no-op pipeline segment `_` might come in useful (although this example is nonsense): `impl (mod|_) local './libs/awesome-library.jar'`

_(Maybe, instead of having `pack` in the dependencies section, allow to add sections via other plugins? `pack` (the equivalent of `include` in fabric-loom) isn't really a dependency)_
\ No newline at end of file