Feat/module interaction/base abstraction
-
Shell Project structure moved under folder src. Folder references fixed in csproj-s and sln. This way solution Shell can be extended with further projects
-
Folder "architecture" with ADRs added to all solutions This folder includes various architecture decision records (ADRs) covering topics such as configuration, solution and project structure, module loading, messaging, observability, security, message routing, built-in APIs, process ownership, script preloading security, module catalog, module loader events, and shell API.
-
Exposing ModuleCatalog:
3.1. IModuleCatalog has been enriched with call GetAllManifests()
3.2. IModuleManifest enhanced with
string[] Tags
Dictionary<string, string> AdditionalProperties
Codecov Report
Attention: Patch coverage is 82.14286% with 5 lines in your changes missing coverage. Please review.
Project coverage is 66.4%. Comparing base (
c089963) to head (3446faf). Report is 10 commits behind head on feat/fdc3-2_0-conformance.
:x: Your patch status has failed because the patch coverage (82.1%) is below the target coverage (100.0%). You can increase the patch coverage or adjust the target coverage.
Additional details and impacted files
@@ Coverage Diff @@
## feat/fdc3-2_0-conformance #987 +/- ##
===========================================================
- Coverage 66.9% 66.4% -0.6%
===========================================================
Files 327 330 +3
Lines 9727 9881 +154
Branches 1169 1189 +20
===========================================================
+ Hits 6517 6568 +51
- Misses 2954 3053 +99
- Partials 256 260 +4
| Files with missing lines | Coverage Δ | |
|---|---|---|
| ...tanley.ComposeUI.AppDirectory/Fdc3ModuleCatalog.cs | 85.1% <100.0%> (+9.4%) |
:arrow_up: |
| ...oseUI.ModuleLoader.Abstractions/IModuleManifest.cs | 40.0% <ø> (ø) |
|
| ...y.ComposeUI.ModuleLoader/AggregateModuleCatalog.cs | 90.2% <100.0%> (+3.5%) |
:arrow_up: |
| src/shell/dotnet/src/Shell/App.xaml.cs | 0.0% <ø> (ø) |
|
| ...ell/dotnet/src/Shell/Fdc3/ComposeUIHostManifest.cs | 100.0% <ø> (ø) |
|
| ...t/src/Shell/Fdc3/ComposeUIHostManifestConverter.cs | 100.0% <ø> (ø) |
|
| ...tnet/src/Shell/Fdc3/ComposeUIHostManifestMapper.cs | 74.2% <ø> (ø) |
|
| src/shell/dotnet/src/Shell/Fdc3/Fdc3Options.cs | 0.0% <ø> (ø) |
|
| ...l/Fdc3/ResolverUI/Fdc3ResolverUIIntentViewModel.cs | 0.0% <ø> (ø) |
|
| ...c/Shell/Fdc3/ResolverUI/Fdc3ResolverUIViewModel.cs | 0.0% <ø> (ø) |
|
| ... and 39 more |
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
Shouldn't this PR target the main branch instead of the feat/fdc3-2_0-conformance?
Shouldn't this PR target the main branch instead of the feat/fdc3-2_0-conformance?
After #989 is merged I'd like to complete the merging of the FDC3 feature branch into main. So in the end, this PR should have targeted the main branch. That being said I saw that files were moved in the solution, including FDC3 related controls such as the ResolverUI. So if it's easier from a rebasing point of view than this PR can target the feature branch until the feature branch is merged into the main. But if it ends up being worse than we can reopen this after the merges are done.
But regardless of what is going to happen in the end for now this PR can say open as is so the team can provide feedback on the abstraction
Shouldn't this PR target the main branch instead of the feat/fdc3-2_0-conformance?
Since ADR-016 explicitly mentions FDC3, it seemed logical to base on feat/fdc3-2_0-conformance. Also it contains leftovers from the .net8 upgrade and some folder refactoring which could mess up merging the feature branch into main.
So I expected this PR to get merged after the feature branch and more urgent PRs are merged into main.