-
Notifications
You must be signed in to change notification settings - Fork 12
Plugins are not handled by Sbtix yet #2
Comments
Do you have an ideas on how to go about fixing this? My research on sbt seems to indicate that the implementers have given very little thought to non connected development of any strip. My approach in supporting Erlang's build system rebar (which has a similar problem) was to actually patch the build system. The down side of that is that rebar in nix is different then rebar everywhere else. The upside is it is impossible for it to hit the network. |
Sort of. SBT allows you to apply plugins to the "plugins project" (and so on, going on forever). So in the worst case it should be doable, with the caveats that the plugin has to be applied "one level higher" than your highest other plugin, and that it would slow down A better solution would be if we could dynamically run the task in the context of those projects as well, but I'm not sure what to do about that... Making SBT load it from our repo afterwards should be a much easier affair: AFAIK, SBT loads the repos to use from the launcher config file, which we can replace with our own that only contains the Sbtix repo. |
Using SBT's global plugins feature might be useful in solving this problem. One shouldn't have to apply the sbtix plugin to all projects in the plugin project chain then. sbtix could provide a script that:
|
Pull request #8 provides a method to easily load the sbtix plugin as a global plugin. It is then possible to run the genNix command against the plugins project with the command: It fails, but attempts to execute:
The error seems to be caused by an inability to find the plugins. Maybe more resolvers are needed? Excerpt from the large error message posted above:
|
This coursier issue might become a problem: https://github.com/alexarchambault/coursier/issues/292 |
adding resolvers to simple example's plugins.sbt seems to almost solve this problem:
With those resolvers in place I get:
and I wonder if it could be because of how sbtix is resolving pom files. Or because it is looking at pom files at all. I think most plugins are stored in ivy repositories and not maven ones because plugins need ivy's extra attributes feature. |
Fixed issue #1 and am now able to generate a repo.nix for the plugin project, it finds the ivy.xml, pom and jar artifacts locally. Am probably going to have a problem when I try to use it though, since I need to build Ivy formatted repos. |
Currently, plugins are still downloaded by SBT from the internet as usual. Ideally Sbtix should download these as well, and add them to the repo.
The text was updated successfully, but these errors were encountered: