OrcharCoreContrib.XXX -> OrcharCoreContrib.Modules.XXX

[hishamco]

Consider rename the assembly to OrchardCoreContrib.Modules.XXX to avoid the conflict that may occurs between OCC & OCC.Modules repo assemblies.

For example OrchardCoreContrib.Localization already provide set of localization APIs implementations, so when we want to create a localization module we will stuck on the naming.

The consequences are:

• Introduce breaking changes
• Need to rename the NuGet packages (which is hard)

[hishamco]

@Piedone I may need your suggestion here

Orchard Core already follow the following pattern:

OrchardCore.XXX.Abstractions OrchardCore.XXX.Core OrchardCore.XXX -> Module

The issue I'm facing here there's no default implementation for some module, for instance localization it has two implementations: JSON & XLIFF. So, creating a module for each one make sense but I can't use the same pattern that OC follows. I'm not sure if you faced similar issue in Lombiq modules

[Piedone]

We're going the simpler route, it's always just Lombiq.ProjectName. This is what I'd suggest. Then, for example for two localization implementations, you can have sub-features (in case of modules) or sub-projects in the same repo, like OrchardCoreContrib.Localization.Json. I wouldn't add Modules here.

[hishamco]

for example for two localization implementations, you can have sub-features (in case of modules)

Sound good but I'd like to make the implementation in different modules something similar to Azure & Amazon media in OC

Again in OCC.Email I have both OCC.Email.Abstractions and OCC.Email for that reason I can create a module with the name OCC.Email instead I wrote module for each implementation. Having them as feature might the way I can go for. But how can I avoid naming collision especially if I have implemenation types like what I have in email and localization

Thanks

[hishamco]

Just revising this one, while OC is a Web Application Framework (WAF) that means it's component could be used without UI parts or notion of module, something similar to OrchardCore.Localization.Core which you can use PortableObjectStringLocalizer in any ASP.NET Core app. That's why we have many OC.XXX.Core to have a default implementation for certain abstractions APIs.

Also having OCC.Modules.XXX will make it easier to look for modules in NuGet similar to OCC.Themes.XXX

[hishamco]

Recently I saw there .Core version for each OC.Search implementation, the reason, we can't use OC.Search.Lucene for instance because the collision that will happen with the module name

From my perspective, the framework APIs could be used in any ASP.NET app, while the modules is something related to the OC CMS