I have an sbt project in which the build is normally invoked via package-tar. If a developer types package, it's very likely that they actually meant package-tar instead.
However, package-tar depends on package. How can I prevent or deter or warn when a developer seems to be making this mistake - since I can't actually disable the package task because it's necessary?
I considered integrating actual deployment into the build, but this is not compatible with our current deployment process.
Instead of making package-tar a separate task, how about just redefining package to do what you want? The new behavior can invoke the old behavior.
http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Artifacts.html has examples of customizing what package does. The material on addArtifact looks relevant.
Related
I have a NuGet package that I have created for my company. It works great. But it includes some code in the System.Net.Http.HttpClient.OAuthClient namespace that is very chatty in the logs at the Information level.
I would like to have my NuGet package automatically add the following line:
"System.Net.Http.HttpClient.OAuthClient": "Error"
At the end of the Logging->LogLevel section of the appsettings.json file of the project it is installed in (if its not already there).
Or failing that, is there a way to suppress these logs down to the Error LogLevel in code?
It's just my personal opinion, and it doesn't answer your question directly, but it did not fit into a comment, so posting it here.
I don't think it's up to your package to decide, what will be in the appsettings.json. There may be let's say production and test appsettings, and in test developers of some projects would actually want to see as many logs as possible.
If your package would modify it, you would take away the decision from developers who use your package. Or, imagine, the project that uses your package also used System.Net.Http.HttpClient.OAuthClient namespace, but for its own purposes. And developers again might want to see logs coming from that namespace.
I'd suggest just to put this info into your package's documentation, and than developers of each project shall decide for themselves, whether they want to suppress logs or not.
Update after comment:
Probably this will get you somewhere: http://www.roundcrisis.com/2014/08/03/Nuget-install-tricks/
The basic idea is that you can distribute init.ps1 script together with your nuget package that will run on installation of the package. And with powershell you could do pretty much anything, including replacing strings in text files.
Have a look also at this SO question: Execute an action after my nuget package is installed
We have custom SBT task which has a dependency (addSbtPlugin). But this plugin is not actually used for compilation and testing, though SBT tries to resolve dependency immediately.
Is is possible to make SBT resolve this dependency only when the particular task is started?
I think this is not possible. If I understood you correctly, what you are asking is similar to "is it possible to resolve a library dependency only when I run the code that depends on it?". If your task depends on the plugin (or is introduced by it), that dependency has to be resolved when the project is loading.
On another note, if this plugin is not related to the project itself and you don't want to force other maintainers to use it, it's a good idea to add it to your global config (which will affect only you and work for all sbt projects on your computer):
place addSbtPlugin in ~/.sbt/1.0/plugins/
if that plugin needs any settings, you can add them to ~/.sbt/1.0/global.sbt
(substitute the version, if you are using older sbt)
For managing and starting processes, in Scala we have the package scala.sys.process.
But SBT have nearly all the classes in that package replicated in the sbt package, with slight variations.
E.g. we have scala.sys.process.ProcessBuilder and sbt.ProcessBuilder.
I wonder:
Why this duplication?
Which one should be used?.
I've decided to use the standard Scala package, but don't know if this the best decision. I've checked that it works ok.
It got imported into scala-library as of 2.9.0, see 5bada81.
I've not seen anyone recommend using Scala's Process API over sbt, so I've continued to use sbt's.
Also in one case with both sbt._ and scala.sys.process._ imports present I've seen IntelliJ throw some false positive errors.
I've been investigating ways to make my Meteor app load faster and so I installed the FastRender package (https://meteorhacks.com/introducing-fast-render.html) and I couldn't believe how quick my Meteor app loads now. It's also rather trivial to add in.
I'm just wondering why this package is not just added by default and work implicitly (instead of having to go fastRender:true, it would be true by default and you would have to go fastRender:false to turn it off). Is there any disadvantage to having this package or any use case where I would not want to turn fastRender on?
Please refer to the fast render page, especially the section "Fast Render exposes some security issues that are not normally issues with Meteor. The following section describes what they are and how to prevent them. Some of the issues have been already fixed.". Fast render is not maintained by the meteor core team, hence it will not be (as of now) a pre-bundled component to the meteor stack
I'm trying to generate code in SBT build for Slick like in the example.
However if I have
fork:=true
setting in the project - build fails with:
java.lang.NoClassDefFoundError: scala/reflect/runtime/package$
I want to keep that option to prevent memory leaks in my unit tests. If I get it right - there is no scala-reflect.jar loaded in forked jvm. But I have no idea how to load it.
I had a wrong assumption that SBT always loads all scala libraries by default, what appears to be incorrect for forked run. If I add scala-reflect dependency explicitly like Seth suggested it works ok.