Feature Request

Create a Morphir Mill plugin that is tasked with wrapping the morphir-elm CLI and will also support direct morphir-scala tasks/commands.

Description of Problem:

Morphir is capable of using its morphir-elm make, morphir-elm gen, and morphir-elm test commands to generate code and run tests.

We have a need to generate Morphir IR and use morphir-elm's code generation capability within Scala builds.

We should create a Mill plugin that allows us to accomplish this.

Potential Solutions:

While we can bootstrap this process by doing Mill specific file and process creation, it should be noted we will want to accomplish the same behavior for abt and scala-cli (and possibly Gradle).

Need to add the actual name of the enum e.g. "MyEnum" into the Enum class.

Feature Request

Description of Problem:

Since upgrading to mill 0.11.x some used types are deprecated, address these deprecations.

[#0] [warn]     Jvm.runLocal("mdoc.Main", cp, dirParams)
[#0] [warn]     ^
[#0] [warn] /home/runner/work/morphir-scala/morphir-scala/project/modules/docs.sc:48:9: value Jvm in package modules is deprecated (since Mill 0.11.0-M9): use mill.util.Jvm
[#0] [warn]         Jvm.runLocal("mdoc.Main", cp, dirParams ++ Seq("--watch"))
[#0] [warn]         ^
[#0] [warn] /home/runner/work/morphir-scala/morphir-scala/project/modules/docs.sc:56:26: type Sources in package define is deprecated (since Mill after 0.11.0-M8): Use mill.define.Target instead.
[#0] [warn]   def docusaurusSources: Sources
[#0] [warn]                          ^
[#0] [warn] /home/runner/work/morphir-scala/morphir-scala/project/modules/docs.sc:57:22: type Sources in package define is deprecated (since Mill after 0.11.0-M8): Use mill.define.Target instead.
[#0] [warn]   def compiledMdocs: Sources
[#0] [warn]                      ^
[#0] [warn] /home/runner/work/morphir-scala/morphir-scala/project/modules/docs.sc:77:[19](https://github.com/finos/morphir-scala/actions/runs/5615735487/job/15216636429?pr=265#step:5:20): value Jvm in package modules is deprecated (since Mill 0.11.0-M9): use mill.util.Jvm
[#0] [warn]     val process = Jvm.spawnSubprocess(
[#0] [warn]                   ^
[#0] [warn] /home/runner/work/morphir-scala/morphir-scala/project/modules/docs.sc:153:14: value Jvm in package modules is deprecated (since Mill 0.11.0-M9): use mill.util.Jvm
[#0] [warn]     val p2 = Jvm.spawnSubprocess(
[#0] [warn]              ^
[#0] [warn] /home/runner/work/morphir-scala/morphir-scala/project/modules/docs.sc:169:5: value Jvm in package modules is deprecated (since Mill 0.11.0-M9): use mill.util.Jvm
[#0] [warn]     Jvm.runSubprocess(

Feature Request

Create a morphir-elm sbt plugin that is tasked with wrapping the morphir-elm CLI

Description of Problem:

Morphir is capable of using its morphir-elm make, morphir-elm gen, and morphir-elm test commands to generate code and run tests.

We have a need to generate Morphir IR and use morphir-elm's code generation capability within Scala builds.

We should create an SBT plugin that allows us to accomplish this.

Potential Solutions:

While we can bootstrap this process by doing SBT specific file and process creation, it should be noted we will want to accomplish the same behavior for Mill and scala-cli (and possibly Gradle).

Feature Request

Description of Problem:

Add support for transforming/encoding from zio-schema to the morphir datamodel.

By supporting zio-schema we will enable additional scenarios

The morphir-tools-launcher should setup the morphir tooling, it should:

• Acquire the Morphir CLI from Maven/Artifactory

Thinks to keep in mind:

• Items should only be downloaded as needed
• We should use a .morphir-version file to control which version of Morphir-cli is downloaded

          A possible issue here is the package name collisions (only one will survive).  Any specific way we should deal with this?

Originally posted by @dmitrykozinets in #462 (comment)

Feature Request

Implement the Morphir.SDK.Bool module in corelib.

Description of Problem:

Provide a definition of the Morphir.SDK.Bool module.

Potential Solutions:

Feature Request

Simplify the project structure:

Description of Problem:

Today we have quite a few modules/projects, which is an artifact of how development has been done (trying some ideas, and wanting to not mix that with core Morphir, as well as previously having a Scala 3 compiler plugin as a goal while wanting to still Support Scala 2).

Today, it feels like there are a bit too many projects (at least for the core of what we are doing).

Potential Solutions:

Going to aim for something along the lines of the following:

.
└── morphir
    ├── build
    │   └── integration
    │       ├── mill
    │       └── sbt
    ├── interop
    │   ├── tapir
    │   ├── vulcan
    │   └── zio
    │       ├── json
    │       └── schema
    ├── knowledge
    ├── macros
    ├── main
    ├── testing
    └── web
        ├── client
        └── server

Let's discuss what we have here:

Here's as summary of the thinking here:

Feature Request

Description of Problem:

...what problem are you trying to solve that the project doesn't currently solve?

...please resist the temptation to describe your request in terms of a solution. Job Story form ("When [triggering condition], I want to [motivation/goal], so I can [outcome].") can help ensure you're expressing a problem statement.

Potential Solutions:

...clearly and concisely describe what you want to happen. Add any considered drawbacks.

... if you've considered alternatives, clearly and concisely describe those too.

Reduce Build Time, by eliminating unnecessary configuration builds.

Currently the GitHub actions builds the project more times than we actually need to.

Firstly:

• ScalaNative and ScalaJS projects don't need to be checked as part of the JVM matrix (building and testing for JDK 11 and 17.

Secondly:

• We should see if cache and reloading build artifacts would help

Create a Windows shell script that can acquire the "morphir launcher" from Maven and start it up with the appropriate Java options similar to maven-wrapper, gradle-wrapper, or millw.

Description of Problem:

There needs to be a way to actually acquire the morphir tooling.
Maven has a decent story around this where it uses the maven-wrapper as a means to use shell scripts to acquire the maven application.
Sbt also has an sbt-launcher which is a lightweight application which setups sbt for execution and pulls down the rest of "sbt proper".
We will use the morphir-tools-launcher jar as a lightweight tool for acquiring the morphir tooling and getting us started. This issue is around creating a shell script that can pull down the morphir-tools-launcher from a maven/ivy style repo like Maven Central or an internal Artifactory instance.

Feature Request

Provide an IRI for each Morphir SDK Type

Description of Problem:

It will be simpler to attribute/annotate the Morphir IR in a meaningful way if we encode the attributes in a manner consistent with RDF we should provide an URI which describes each morphir SDK type that is rooted at: https://morphir.finos.org/shemas/sdk.

Potential Solutions:

We should provide these URIs/IRIs in both documentation and code form.

Feature Request

Create a bash script that can acquire the "morphir launcher" from Maven and start it up with the appropriate Java options similar to maven-wrapper, gradle-wrapper, or millw.

Description of Problem:

There needs to be a way to actually acquire the morphir tooling.
Maven has a decent story around this where it uses the maven-wrapper as a means to use shell scripts to acquire the maven application.
Sbt also has an sbt-launcher which is a lightweight application which setups sbt for execution and pulls down the rest of "sbt proper".
We will use the morphir-tools-launcher jar as a lightweight tool for acquiring the morphir tooling and getting us started. This issue is around creating a shell script that can pull down the morphir-tools-launcher from a maven/ivy style repo like Maven Central or an internal Artifactory instance.

Feature Request

Provide an IRI for each Morphir IR Node

Description of Problem:

It will be simpler to attribute/annotate the Morphir IR in a meaningful way if we encode the attributes in a manner consistent with RDF we should provide an URI which describes each morphir SDK type that is rooted at: https://morphir.finos.org/shemas/ir.

Potential Solutions:

We should provide these URIs/IRIs in both documentation and code form.

In Morphir datamodel use the same Name, Path, PackageName, QName, etc. naming objects used by the IR.

Currently we have separate naming primitives, but once we consolidate the IR and Datamodel into the same project, it will be easier to use the same naming structures.

Depends On: #275

Feature Request

Description of Problem:

Running docusaurus build and serve using mill takes a long time to finish.

Potential Solutions:

...clearly and concisely describe what you want to happen. Add any considered drawbacks.

... if you've considered alternatives, clearly and concisely describe those too.

Feature Request

Description of Problem:

Add support for transforming/encoding from tapir to the morphir datamodel

Feature Request

Description of Problem:

Add support for generating the Morphir Datamodel (MDM) from Avro through Vulcan

Update GitHub Actions CI build to accomodate cross-platform.

We could use portions from this for an example: https://github.com/com-lihaoyi/upickle/blob/main/.github/workflows/actions.yml#L14-L73

The goal is to be able to separate: JS, JVM, and Native builds out (note native is for all intents and purposes disabled but work is in progress to enable it shortly)

Feature Request

EvaluationLibrary.scala, and its platform specific variants, should be removed. Loading distributions should be on the Distribution companion object.

Description of Problem:

This fils is old and vestigial. The core of its functionality was removed long ago, and it only endures because it implements the platform specific behavior needed to work around a js compatibility issue (which hopefully will cease to be a problem soon.)

Potential Solutions:

Remove EvaluationLibrary
Add loading code to Distribution
If ZIO does not have cross-compiling file support by the time this is done, include platform specific supertraits of Distribution

Feature Request

MorphirRuntime has a number of ZPure functions. In at least one upcoming case (unit testin'), these can only be called after the user has performed some side effecting operations to get the required inputs. It would be helpful to have ZIO versions as well to wrap this functionality, which is not something that fits into the model of ZPure

Description of Problem:

Very specifically, when calling runUnitTests, I should not have to provide the unit test framework IR myself; there should be at least one entry point that loads it for me.

Potential Solutions:

It should be fairly easy to add ZIO versions of these functions with support for file handling (esp. once cross-compiled file handling with js has been resolved)