Is it possible to have task-dependent SBT dependencies? - sbt

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)

Related

Is there a easy way to protect, or revert Qt source code?

I just accidentally refactored QList to QSet, and Qt faithfully did it, to all of its own sources too... (yup, that was dumb!)
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
There's no point to using source code control for an install: it's not source code. It's artifacts. You already know how to protect artifacts of all sorts from modification. Proper filesystem attributes will do it just fine.
Your finished Qt installation should not be writable by you. It would be by default on Unix systems when installed using a privileged package manager. Elsewhere: you need to make it read only. If you build from source, then recursively making the install folder read-only as the last step after installation is all it takes; and since you should be already automating your Qt build, then adding the "make read-only" step is trivial.
Thankfully my code is source controlled, I just reverted everything, would it be feasible/sensible to make a git repo for the Qt sources too? (I have the free version so I didn't think I could modify them anyway...?)
Feasible? Definitely. Sensible? Perhaps, assuming that by "make a git repo" you mean "cloning the official Qt repos from Git". It depends on how many times you plan on making the same renaming mistake. :D But seriously, I think there are benefits to building Qt yourself:
You can easily debug and check the implementation of API that you're using.
You can configure Qt to skip building stuff that you're not interested in.
You can easily patch Qt if there's a bug that you know of a fix for but hasn't been merged into Qt itself yet.
There are downsides too, though. You might run into build issues if you're using configure flags that the CI doesn't use (such as a -no-foo option). It can take a while to build depending on how many submodules you have and what kind of machine you're building on.
In general, if you're not using API that's in dev and not yet released, it's probably not worth bothering.
If you're still interested, this page has instructions for building Qt from Git:
https://wiki.qt.io/Building_Qt_5_from_Git
Is there a hidden setting that will prevent its sources from being modifiable, to stop me from doing this again?
Couldn't you set some permissions on the source directory? I've never had to do this, but have been bitten by it on unrelated occasions before, so I know it works. :D
I'm currently using the maintenance tool to install a newer version of Qt, but other than update or add/remove, there wasn't a re-install option that I could see, am I missing something?
Remove and add is your only option, I think. Otherwise, you can always keep a backup of the source by just copying the whole directory.

Is it necessary to use gradle with roboelectric for android unit testing?

I and my team have built up an android library project. it is built up on eclipse but we are using ant to build it. Presently we aren't using gradle. I have a roboelectric with dependencies jar file instead. But when I use this, while running the unit tests, the following error comes up
WARNING: multiple versions of ant detected in path for junit
[junit] jar:file:/Users/prateekarora/Desktop/eclipse/plugins/org.apache.ant_1.9.2.v201404171502/lib/ant.jar!/org/apache/tools/ant/Project.class
[junit] and jar:file:/Users/prateekarora/trunk/client/android/MCCMobileClient/test2/libs/robolectric-2.3-with-dependencies.jar!/org/apache/tools/ant/Project.class
When I remove the apache ant from eclipse's plugin folder, this stops working.
Can Anybody explain why this is happening?
Also, is it necessary to use roboelectric with gradle? If no, where can I find the roboelectric's jar files with/without dependencies?
It is not necessary to use gradle with robolectric. It is just about running specified java class (from junit) with proper classpath (including you source, test code and dependencies). Fixing your case is not something that is easy to make over stackoverflow (it will be some challenge even if you sit behind same computer).
Here are possible solutions:
Migrate your project build to the gradle
Keep using ant but move from dependency management from manuals jars to ivy
Keep using ant and manual jars dependency, but try to get robolectric.jar with all dependencies except ant one
The first one option is the easiest option as for me. It will require to change mindset a bit but this is officially only one supported build tool by Google as well there are a lot of examples and people that could help.
The second one also require you to learn how to use new tool. As well there less examples about ivy usage especially in android projects.
The third one will require to write custom script that removes ant from jar file or to rebuild robolectric-all.jar without one (ant) dependency. This will require to dive into maven build tool learning

What is the implication of exportjars := true?

I've just started using an sbt plugin for packaging JavaFx/ScalaFx applications sbt-javafx. This under Java 7.
While the plugin seems to work pretty well, it is not able to properly package multi-module project. A workaround they have found is to use exportsJars := true in all the modules on which the JavaFX modules depends on.
I also have IntelliJ IDEA that can produce a JavaFX application for me, though that would break the automated build. I'd very much like to have the executable automated.
I need to understand the broad implication of that parameter on my sbt build. Why is the setting needed to be true?
Here is the help definition:
Determines whether the exported classpath for this project contains classes (false) or a packaged jar (true).
It sounds like by default it's false. Why?
p.s. If someone has a cleaner solution to package JavaFX/ScalaFX applications using sbt, please feel free to share.

sbt: Prevent erroneous command being issued?

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.

STS: Losing references in Java Build Path

I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.

Resources