-
Notifications
You must be signed in to change notification settings - Fork 113
Allow SbtUpdateReport to provide arbitrary artifact files, not just jars #113
Comments
@NicolasRouquette sorry for keeping you waiting for so long. Yes, it could be an option to pass that selector in. Could it be enough to pass in a Set of file extensions or types, instead? Can you explain when this problem arises? Should we also fix the default behavior? |
Where does this problem come from?This problem arises from several use cases where it is necessary to retrieve a filtered set of Maven artifacts from the transitive dependencies of a given project.
Limitations in the current logicThe logic only handles 1 artifact per module; this logic doesn't work where we need to get in the graph nodes corresponding to multiple artifacts published for a given module. A peculiar need arose when I had to publish an artifact to bintray that exceeded the 250 mb limit for OSS repos. In this case, I published the artifact in multiple parts of 250 mb or less; e.g: An an improved version of fromConfigurationReport to handle multiple artifacts per module is below:
Filtering criteria: do we need the Artifact + File or could we pass file extensions/types.I think a filter operation predicated on the Artifact + File gives us reasonable flexibility to accommodate various needs. It's unfortunate that the filter doesn't have access to the organization info; this is something that I find particularly useful with low-level filtering with SBT's update. Why use dependency graph instead of SBT's update report?Before using the dependency graph, I was using SBT's update report to retrieve a filtered subset of dependencies I needed. This worked most of the time except when we began using version range dependencies; e.g.:
First, we can't use the SBT maven resolver plugin in this case because of known limitations (See: http://www.scala-sbt.org/0.13/docs/sbt-0.13-Tech-Previews.html#Maven+resolver+plugin). Second, we noticed some odd behavior where SBT's update report doesn't always provide information about the latest artifact available. For example, if the local ivy cache has, say, version 1.0.0 but the repo has version 1.0.1, then I noticed that dependency graph would give us the current up-to-date info whereas SBT's update report didn't. I am really dumbfounded by this difference. I am not sure how I could make a reproducible case of this peculiar behavior. What I do know is that the SBT dependency graph does provide current up-to-date info and that's why I've updated a lot of my SBT scripts to use it instead of the SBT update report. Proposal
|
net.virtualvoid.sbt.graph.backend.SbtUpdateReport.fromConfigurationReport()
has a hardcoded rule for selecting a "jar" file for a givenModuleReport
:https://github.com/jrudolph/sbt-dependency-graph/blob/master/src/main/scala/net/virtualvoid/sbt/graph/backend/SbtUpdateReport.scala#L37
It would be helpful to pass an artifact file selector to this function; something like this:
A selector function could be then defined like this:
I suggest adding a new setting key with a selector function that could be customized for a project with
jarFileSelector
as the default for backwards compatibility with the current behavior.The text was updated successfully, but these errors were encountered: