Orchard Core APIs Separation

[hishamco]

One of the most frastration thing in Orchard Core for new comers is they can distinguish between Framework vs. CMS APIs, my suggession to split the APIs logically or physically without breaking things

The main idea to make everything clear, something like Modules, we already have Core modules vs CMS modules

[TFleury]

Are you talking about distinct repositories ?
In a recent comment @deanmarcussen talked about splitting code in separate repositories, which i think could be a good idea.

Maybe we could have :

• "OrchardCoreFramework" (Everything in OrchardCore solution folder that is not related to content management)
• "OrchardCoreCms" (Everything in OrchardCore solution folder that is related to content management)
• "OrchardCoreModules" (Everything in OrchardCore.Modules solution folder)
• "OrchardCoreCmsModules" (Everything in OrchardCore.Modules.Cms solution folder)
• "OrchardCoreThemes" (Everything in OrchardCore.Themes solution folder)

It may help to isolate issues and maintain clean dependency graph, but it could also be more work to maintain repositories, consistent versioning and CI pipelines.

Or if we don't want multiple repositories, as you suggest, maybe just create an "OrchardCore.Cms" solution folder and distinct solution files.

[hishamco]

Are you talking about distinct repositories ?

Exactly

[hishamco]

We may consider using Submodules, Lombiq is already has a very good experience using them, I'm just learn about them ;) for that I will let @Piedone explains the pros & cons for using Git Submodules

[hishamco]

The main reason, why I need bother myself to have the entire source for something I'm not intereset in? Assume I need a PO Localization for instance, in the current situation I need to have clone both Framework & CMS APIs

In Nutshell we offer both Framework & CMS APIs, but almost the audience accidentally consufe between the distinction of which APIs are related to CMS and which for Framework

[Piedone]

But this is only for contributors. Is perhaps optimizing out a few MBs of Git clone and a few seconds during the first build after a fresh clone really worth making managing the solution harder by making Orchard span across multiple repos? (I get the idea, I think, but it's a solution for an issue we don't really have.) For consumers of Orchard packages, nothing would change and nothing would be clearer, either, by reorganizing the source code the exact same packages are built from.

[hishamco]

For consumers of Orchard packages, nothing would change and nothing would be clearer

Right, but I'm suffering when I create a PR, the build tasks much time because there are more 175 projects, which makes my laptop handing ;)

[Piedone]

We could perhaps better solve this with different solution files, though that'll be a hassle to maintain as well. Have you tried doing that just for yourself though, or at least unloading projects you know you won't need?

[hishamco]

I already created a PR #10436

or at least unloading projects you know you won't need?

I'm always doing that but sometimes I notice a build issues, especially in test projects, because unloaded projects are not included :(

[TFleury]

When I wrote my comment, I was trying to setup a modular app with admin UI but without any CMS feature nor YesSQL.
This scenario was - at that time - quite impossible to achieve because some features was tightly coupled to YesSQL and other CMS related modules.

That said, I don't think Git sub-modules would be easy to maintain.

[hishamco]

I didn't suggest Git SubModules as a best options, but separation of both Framework & CMS APIs will have many values for Framework developers, CMS developers .. ect