switch to module

[thompson-tomo]

Fixes #348
Design discussion issue #

Changes

This proposes a new project structure which enables an improvement in build performance by adopting a modules approach and enabling the build system to manage what is built.

Some of the other benefits is that

• CPM is natively supported hence enables improved package management
• The process to add new components is documented with the need to modify existing file's is decreased to be only 2 spots including code owners
• Solution can exist side by side while migration occurs
• Solution filters are leveraged to improve developer and build experience
• No changes necessary to implement AOT tests
• Proj files are not needed due to solution filters handling that use case
• Simplified codecov reports due to reduced build
• Improved pr views due to natively determining steps rather than skipping them hence bringing count down
• Decreased build time & processing time. Even when performing the same tasks 20% reduction has been achieved.
  • https://github.com/open-telemetry/opentelemetry-dotnet-contrib/actions/runs/16395177687/usage (latest) vs https://github.com/open-telemetry/opentelemetry-dotnet-contrib/actions/runs/16387795471/usage?pr=2884 (same structure as previous)

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[thompson-tomo]

Awaiting feedback

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[thompson-tomo]

Awaiting feedback

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[thompson-tomo]

Awaiting feedback

[Kielek]

@thompson-tomo, I am closing this PR. I doubt that it will bring CI pipeline to the better shape. For sure, it will be even more problematic than now.
Module, is not .NET concept, it could bring even more complication for the contributors.

If you want to work with some subsets of projects, you could try https://learn.microsoft.com/en-us/visualstudio/ide/filtered-solutions?view=vs-2022

The only thing we could consider for this project is Central Package Management, but it can be achieved without restructuring whole repository.

[thompson-tomo]

@Kielek I am confused by you responses.

I doubt that it will bring CI pipeline to the better shape.

Not sure how you measure this but for me 20% build time reduction & significantly more readable PR actions for me puts pr's in a better shape.

Module, is not .NET concept, it could bring even more complication for the contributors.

Maybe module is not the best term but that can easily be changed. In fact a number of other otel contrib projects split it based on functionality ie propagator.

If you want to work with some subsets of projects, you could try https://learn.microsoft.com/en-us/visualstudio/ide/filtered-solutions?view=vs-2022

If you look at the pr, you would see the proposal here is to use solution filters rather than proj files.

The only thing we could consider for this project is Central Package Management, but it can be achieved without restructuring whole repository.

I agree CPM can be used without restructuring it, but by restructuring it makes it easier to achieve small scoped pr's which is clear on what packages are impacted without workarounds.

As it appears the biggest concern is about moving to the module/component based folder structure, please reopen so I can move the files back and make the changes to achieve the same outcome using existing folder structure.

[martincostello]

20% build time reduction

Maybe nice to have, but the build time is not really a limiting factor on any contribution being accepted.

more readable PR actions for me puts pr's in a better shape.

I don't think we need main and PR versions of all the workflows - it just creates more duplication and things to maintain (e.g. PR passes, you merge and then find the main version didn't get updated).

Restructuring all the workflows will also impact the required PR status names and need the repository settings updated.

other otel contrib projects split it based on functionality

They may, but they are different projects with different maintainers and different technologies. I don't think its worth churning the codebase to move everything around and remove the consistent repository layout.

the proposal here is to use solution filters rather than proj files.

dotnet/aspnetcore is the only open source I've personally interacted with that's used .slnf files, and I find them in practice to be poorly maintained, and they have a low exposure rate amongst the typical .NET developer, so it's likely to create a barrier to entry for the average contributor.

They can also cause issues if you need to touch a file that impacts many projects (e.g. semantic conventions or common MSBuild targets), as you can miss issues locally that you don't find due to not eveything being compiled if such a change is made, then it's only found at CI time.

There's a trade off between only needing to compile the bare minimum of things touched and building a larger set, but that's a hard problem to definitively determine already with regards to building the exact right amount of things relevant for a given change, and I don't think .slnf files will make a difference.

without workarounds

Not sure what workarounds you're referring to. CPVM can be adopted without restructuring all the code, and specific projects will still have different version opinions (e.g. library (pinned) vs. tests (tracking latest)).

---

This PR is trying to introduce far too many changes in one go, and I don't think the majority of the proposed changes are actively wanted to be pursued by the maintainers.

A new, separate, PR to adopt CPVM (without changing any versions used by anything) would be welcome.