You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, one of the "source dependencies" are listed as the only limitation of dependency locking.
Current Behavior (optional)
No response
Context
We've only recently started using Gradle. We use source dependencies, because the language plugin we're using doesn't provide support for publishing artifacts to repositories and resolving dependencies from there. This is mostly because the compilers we are using are not really built for binary integration.
For direct dependencies we use strict fixed versions, so this gives us some control. This doesn't affect transitive dependencies though. I can't really see a real alternative to locking here, aside from specifying dependency constraints on each and every dependency in the build. This could get pretty unwieldy.
The text was updated successfully, but these errors were encountered:
This feature request is in the backlog of the relevant team, but this area of Gradle is currently not in focus. It might take a while before it gets implemented.
I'm not sure whether this is a major thing or just requires some touch ups here and there. If someone could hold my hand a bit, I'd be open to working on it.
Thanks for the offer to help. This particular feature isn't under active development and never really reached full maturity.
I don't know the full scope of what would need to change, but it would be deep in dependency-management.
IIRC, the reason that dependency locking doesn't apply to source dependencies is that source dependencies appear to Gradle as project dependencies instead of external dependencies.
Since this isn't an active area, I can't offer more guidance than that.
As an alternative to source dependencies... since your toolchain doesn't really support building binaries, you could consider just assembling all of the separate repos into a large composite build and manage which tags get checked out outside of Gradle.
@big-guy I use source dependencies to consume separate libraries and I use Gradle exactly for figuring out what has to get checked out. I was thinking of updating my plugins for producing artifacts, which merely consist of the sources and some metadata. This way it would look like "binaries" for Gradle, but they could be used to do source integration.
Expected Behavior
Currently, one of the "source dependencies" are listed as the only limitation of dependency locking.
Current Behavior (optional)
No response
Context
We've only recently started using Gradle. We use source dependencies, because the language plugin we're using doesn't provide support for publishing artifacts to repositories and resolving dependencies from there. This is mostly because the compilers we are using are not really built for binary integration.
For direct dependencies we use strict fixed versions, so this gives us some control. This doesn't affect transitive dependencies though. I can't really see a real alternative to locking here, aside from specifying dependency constraints on each and every dependency in the build. This could get pretty unwieldy.
The text was updated successfully, but these errors were encountered: