Conditional addSbtPlugin based on scalaVersion - sbt

I'm using a plugin (sbt-scapegoat) which only works for Scala 2.11.
Can I have a conditional addSbtPlugin based on scalaVersion? Like:
if (scalaVersion.value.startsWith("2.11")) addSbtPlugin("com.sksamuel.scapegoat" %% "sbt-scapegoat" % "0.94.6")
How can I do this in SBT?
Jianshi

tl;dr It's not possible given the description of the problem.
There are at least two build configurations involved in a sbt project - the real project (you want to bet your money on) and the meta build for the build of your project. Yes, I know it sounds a little weird, but it's a very powerful concept IMHO.
See sbt is recursive:
The project directory is another build inside your build, which knows how to build your build. To distinguish the builds, we sometimes use the term proper build to refer to your build, and meta-build to refer to the build in project. The projects inside the metabuild can do anything any other project can do. Your build definition is an sbt project.
sbt runs atop Scala and requires a strict version of it. No way to change it unless you fancy spending time on things you should really not be touching in the first place :)
What you can do is to apply the plugin in project/plugins.sbt and then, in the project, apply the settings of the plugin selectively, per scalaVersion of the project's build not the meta-build's itself.
It's not that complicated as the answer reads, but explaining simple concepts is usually not an easy task for me. Have fun with sbt! It's gonna pay you back very soon when used properly.

Updated answer for 2020: You can use .filter on addSbtPlugin.
For example, the following works:
val scalafixEnabled = System.getProperty("SCALAFIX", "").trim.nonEmpty
addSbtPlugin("ch.epfl.scala" % "sbt-scalafix" % "0.9.14").filter(_ => scalafixEnabled)

Related

Custom gradle plugin - buildscript dependencies

I am trying to write a custom gradle plugin (kotlin/kotlin dsl) that will allow me to set all sorts of things in the build scripts.
I would like to add dependencies on build tooling, such as detekt, log4j2, ktlint, and even configure them. So for example, including the plugin will add detekt tasks to the build.
I have a basic binary plugin with a task, but I am having difficulty constructing a good web-search to find what I need. Can anyone please:
provide some clues
give me some search terms
point me at an article
or point me at a good example?
Thanks in advance.
Phill
Edit: this plugin class compiles, and seems acceptible to the receiving build script, but no detekT tasks appear in the receiving build.
class BuildCommonPlugin: Plugin<Project> {
override fun apply(project: Project) {
project.dependencies
.create("io.gitlab.arturbosch.detekt:1.19.0")
}
}
EDIT: At the comment I am using a 'buildSrc' type plugin. The irritating thing is that I need to duplicate this in each grade project, and when I find an improvement I need to update them all.
How easy is it to convert a 'buildSrc' into a publishable plugin?

I want to generate boiler plate code in my repository pattern project

As title suggests, I am creating open source project that is in .net core 2.0. here is the architecture of it.
Now, it's working fine with everything including code first, seeders, swagger UI, TDD etc.
But there are many places where I have to add/modify classes when I want to add new Table in Database (see SimpleCRUD.Model > Entities)
So, I think I can reduce that boilerplate code, but I am not sure what is best way to do it.
What I did so far?
I tried to create a windows app, which will check and generate code for new added entity.
What I am trying to achieve?
Is there anyway I can add some kind of code in my current project and that will check after each build? is it feasible? any other suggestion to make it working perfectly?
Reference
I have checked this working in few other frameworks like serenity, asp.net boilerplate etc.
T4 temples can help cut down the boiler plate...
https://dotnetthoughts.net/generate-your-database-entities-using-t4-templates/
You've asked for my help here
I agree with other posters that you might want to look into T4. It sounds like you also want to create an MSBuild task.
I outlined the steps to do this for a different question in post here
You can find my code generators under this folder, CodeGen.SessionProxies
The t4 example can be found here: AppSessionPartials.tt
The MSBuild task can be found here: GenerateSessionProxies.cs
I had it generating a nuget file through the CodeGen.SessionProxies.nuspec. You won't find it on nuget.com; I had a local nuget repository. It would be helpful to you to look at the corresponding install.ps1 to understand how to set the generator up as a msbuild task.
Disclaimer: All of the GitHub links are subject to break if I ever decide to clean up that repo.
Cheers

Closure: --namespace Foo does not include Foo.Bar, and related issues

I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:
FooLibrary.Bar
FooLibrary.Qux.Rumps
FooLibrary.Qux.Scrooge
..
Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.
First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
This is my main issue.
However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "#export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:
goog.requireRecursively('FooLibrary')
in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.
I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.
You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.
If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.
First, I need closurebuilder.py to send the full list of files to the closure compiler. ...
In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that #require's everything. Surely that can't be right?
You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.
What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?
You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.
What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.
My GeolocationMarker library has an example of this strategy.

Flex application versioning

I'm not referring to CVS or SVN! The thing I would like to do is:
I want to have a version number of the application ex. 0.0.120
I want to see this version number only in the About box or similar
This version number should change everityme I hit debug or release. ex. my version was 0.0.120, after I hit debug in the FlexBuilder, the versionNumber should change to 0.0.121, but If I press Release Build, then the version should change to 0.1.0
The first number changes only when I manually change it
Don't know how is this possible but if you have a tip, let me know. Thanks!
Have a look at this article http://www.igorcosta.org/?p=220. I use this method to keep tract of compilation date of my swfs.
Credits goes to Paul Sivtsov.
I think Flex Builder doesn't have this out of the box, but you can build ant script for that and build your application with it:
http://blog.nirav.name/2008/02/how-to-auto-increament-version-build-id.html
This is typically something you support with frameworks such as maven.
There is actually a maven plugin for flex here
mico's trick is nice though

Adding additional make/test targets to an autotools project

We have an autotools project that has a mixture of unit and integration tests, all of which run via 'make check'. This isn't ideal, as some of the integration tests take a while, and have all sorts of dependencies (database, etc.)
I'd like to separate the integration tests and assign them their own make target. That way, unit tests can still be run often (via make check), and the integration tests can be run as needed in a similar fashion.
Is there a straightforward (or otherwise) way to add an additional make target?
NOTE: I should probably also add that this is a large project, so editing/maintaining every makefile by hand is not desirable. I'd like to do it the 'autotools way' if possible.
-- UPDATE 1 --
I've attempted Jon's solution, and it's a step closer, but not quite there. I still have a couple of issues:
1) Recursion - I'm OK with modifying the makefile.am in the root of the build tree, as well as any directory that contains the tests, but it seems like there should be a way to do this where I don't have to change every Makefile.am in the hierarchy. (the check target works this way, after all)
2) .PHONY - I keep getting messages about .PHONY being redefined. Which is understandable, because it's being set by another package (specifically, doxygen). How do I make the two play nice together?
In your am files, all make syntax is passed into the generated Makefile. So if you want a new target just create it like you would in a Makefile and it will appear in the auto generated Makefile. Put the following at the bottom of your am files.
integration-tests: prerequisites....
commands to run test
.PHONY: integration-tests
Since there haven't been any more responses, I'm going to answer with my solution.
I solved the recursion issue by eliminating the recursion altogether. Using this page
as a guide, I switched the entire project from recursive make to non-recursive make. I then cloned the non-recursive check-related targets (check, check-am, check-TESTS, etc.) into a new set of targets for the integration tests. So far, this works extremely well.
Note: you may be wondering why I didn't just clone the recursive targets instead. Quite frankly, I couldn't find them. Either I didn't know where to look (the rules weren't in the generated Makefile) or something is happening implicitly, and I don't understand autotools well enough to follow it.
As for the issue with .PHONY being redefined, I still haven't found a solution, other than to conditionally exclude the other definition when I'm doing the integration tests.

Resources