I would like to use scalameta to parse ALL source code files from an SBT based Scala project and transform them.
As the documentation states (https://scalameta.org/docs/trees/guide.html#from-programs-with-multiple-top-level-statements) I can parse SBT files with scalameta but how do I get the corresponding source code files of the project?
Do I have to filter for all .scala files in the src/main/scala folder manually?
As written in documentation about SemanticDB they added a function to work with all .semanticdb files to internal package. I guess you can do similar thing with .scala or .sbt files. Well, basically, yes, it's on your own.
https://github.com/scalameta/scalameta/issues/1566
https://github.com/scalameta/scalameta/blob/master/semanticdb/semanticdb/src/main/scala/scala/meta/internal/semanticdb/Locator.scala
Here is example how to handle all source files in a directory with sbt + Scalameta https://github.com/DmytroMitin/scalameta-demo
Related
How can the scala source files of a project be included in the generated target jar produced by sbt pack?
Currently, when an IDE user of my jar tries to jump to a function in the library they will only get decompiled version of the code instead of the original source. However, other libraries pull from artifact repositories have the ability to jump to the original source code.
Thank you in advance for your consideration and response.
I think you can use:
packageSrc: Creates a jar file containing all main source files and
resources. The packaged paths are relative to src/main/scala and
src/main/resources. Similarly, test:packageSrc operates on test source
files and resources.
sbt Command Line Reference
I am not sure how to split the build.sbt file in a Play project. Usually in the Play projects I have seen only one build.sbt file, but the project I am referring to have multiple build files in addition to the build.sbt file like:
build.checkstyle.sbt
build.findbugs.sbt
build.junit.sbt
I am not sure if they have split the build.sbt file or is it something else all together. Can anybody help me understand what is happening here?
One more thing is I know what are the purpose of these files like the checkstyle file is used for code style checking and the junit file is for the unit testing. These functions are working perfectly fine, but what I am struggling to understand is how/where did they configure it. I mean these files are not imported by the base build.sbt file so how is the configuration done?
This is just how sbt works. It scans your project for .sbt files, not only a build.sbt file. From sbt docs:
Any time files ending in .scala or .sbt are used, naming them build.sbt and Build.scala are conventions only. This also means that multiple files are allowed.
So, basically, at the mentioned project, people decided that it would be better to split the settings in different files. There is nothing special to do and sbt will handle that for you. Another example is Playframework itself:
https://github.com/playframework/playframework/tree/master/framework
See how it have a build.sbt and a version.sbt files. This is also just a convention so that you can configure the project version at a separated file (which is understood by some sbt plugins, like sbt-release).
I have a directory that I want to use as a dependancy for an sbt project however its comprised of .scala files which means I can't place it inside a jar (from what I understand) so then how can I use it as a dependancy for my project?
(sbt doesn't have it as a managed dependancy)
thanks in advance
as written in the manual, you can customize the sources (or source directories) pretty freely. by default, sbt will expect to have scala and java sources under a source directory.
you can customize that too. depending on your exact use case, maybe you want these sources under a different configuration? if it's just extra sources to compile and package, you can simply use:
sourceDirectories in Compile += file("/path/to/your/sources")
or:
unmanagedSourceDirectories in Compile += file("/path/to/your/sources")
use the first when the sources are managed, e.g: if these sources are generated by some other program, or retrieved as a dependency, etc'...
use the second when these are plain sources not managed by anything.
I have no Scala experience, but I need to create a JAR to include on a project's classpath from a single Scala source file.
I'm thinking there is a relatively straightforward way to do this, but I can't seem to figure it out.
The Scala file is here: http://pastebin.com/MYqjNkac
The JAR doesn't need to be executable, it just needs to be able to be referenced from another program.
The most convenient way is to use some build tool like Sbt or Maven. For maven there is the maven-scala-plugin plugin, and for Sbt here is a tutorial.
If you don't want to use any build tool, you may want to compile the code with scalac and then create the jar file manually by using zip on the resulting class files and renaming it to jar. But you have to preserve the directory structure. In your pastebin you use the package org.apache.spark.examples.pythonconverters, so make sure the directories match.
Btw, if you want to just integrate this piece of code with your java project, and using maven, you can have the scala code in your 1 project as well (in src/main/scala). Just use the maven-scala-plugin plugin and hook it to the compile phase, or some sooner phase if your Java code depends on it. However, I don't recommend mixing multiple languages in one project, I would split it into two separate ones.
I am trying to convert an existing Maven multi-module project over to use sbt instead. One of the module subdirectories has .scala at the end of its name (because it's a pure Scala implementation of a library that was originally written in Java). Maven had no problem with this. However, sbt sees the .scala and thinks that the directory is a Scala source file and tries to compile it, which fails, of course.
How can I configure sbt so that it doesn't try to compile a directory as a source file? Note that the top-level (root) project doesn't contain any source code itself, so disabling compilation altogether at that level would be an acceptable solution (as long as it doesn't prevent the submodules from being compiled).
Yes, I have considered simply renaming the submodule directory so that it doesn't contain .scala, but I would prefer to avoid restructuring my build tree if possible.
Let's say the name of your directory is ./directory.scala (located in the root of the project). Then this should do the trick:
excludeFilter in Compile := "directory.scala"