Cococapods: Clean-up the lockfile data model #11085
Open
+55
−89
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fviernau
force-pushed
the
cococapods-lockfile-model-improvements
branch
from
b473ca4 to
2e2e47a
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #11085 +/- ##
=========================================
Coverage 57.38% 57.38%
+ Complexity 1703 1701 -2
=========================================
Files 346 346
Lines 12833 12833
Branches 1218 1218
=========================================
Hits 7364 7364
Misses 4999 4999
Partials 470 470
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
fviernau
force-pushed
the
cococapods-lockfile-model-improvements
branch
4 times, most recently
from
50191db to
27ea0af
Compare
sschuberth
reviewed
Nov 14, 2025
Member
sschuberth
left a comment
sschuberth
left a comment
There was a problem hiding this comment.
For the record, I'm not a big fan of making DependencyHandler implementations stateful. I like APIs that ensure correct use at compile-time, but with the stateful design you have to remember to call setContext() and will only realize at runtime that something is wrong.
I know that the Yarn implementations already are stateful, too, and that we have no clear rule in favor or against this. I just wanted to share my opinion.
I also think that @bs-ondem should share his opinion as he contributed the withResolvedPaths() logic.
plugins/package-managers/cocoapods/src/main/kotlin/CocoaPods.kt
Outdated
Show resolved
Hide resolved
Simplify an upcoming change. Signed-off-by: Frank Viernau <[email protected]>
Prepare for making `Dependency` a non-inner class again. Signed-off-by: Frank Viernau <[email protected]>
Remove mixing the upstream data model with means for mapping it to ORT's model. Also revert back to a non-inner data class, which removes unnecessary complexity. Signed-off-by: Frank Viernau <[email protected]>
Clearly separate the upstream data model, and simplify things by turning the class into a non-inner data class again. Signed-off-by: Frank Viernau <[email protected]>
Remove complications which have become unnecessary with recent changes in `Lockfile`. Signed-off-by: Frank Viernau <[email protected]>
Make the names a tad more speaking and consistent. Signed-off-by: Frank Viernau <[email protected]>
Signed-off-by: Frank Viernau <[email protected]>
Signed-off-by: Frank Viernau <[email protected]>
fviernau
force-pushed
the
cococapods-lockfile-model-improvements
branch
from
27ea0af to
b456617
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Clearly separate again the upstream data model, from means to mapping it to ORT's model.
Furthermore, eliminate complexities related to the use of inner classes and mapping a
Lockfileto anotherLockfile, e.g inwithResolvedPaths().There was also a hidden requirement to not access the (now removed) lazy properties too early.