I am new to SBT. Just be curious that why does sbt's gen-idea always generate two IntelliJ projects:
.idea
.idea_modules
When I open the generated project, the "project" directory is always there as a separate project different with the top level project. The name is "myproject-build".
Just wondering whether this is normal?
Thanks.
Yes this is normal, this is the default behavior. You can change it by excluding some folders (see the doc available here : https://github.com/mpeltonen/sbt-idea at Exclude some folders)
So what is the difference between .idea and .idea_modules?
.idea_module generates an IDEA module while .idea generates an IDEA project.
In short a project can be multi-module or single-module and also contains IntelliJ libraries.
In longer version from the doc (http://confluence.jetbrains.com/display/IDEADEV/Structure+of+IntelliJ+IDEA+Project)
Project
In IntelliJ IDEA, a project encapsulates all your source code,
libraries, build instructions into a single organizational unit.
Everything you do in IntelliJ IDEA, is done within the context of a
project. A project defines some collections referred to as modules and
libraries. Depending on the logical and functional requirements to the
project, you can create a single-module or a multi-module project.
Module
A module is a discrete unit of functionality that can be run, tested,
and debugged independently. Modules includes such things as source
code, build scripts, unit tests, deployment descriptors, etc. In the
project, each module can use a specific SDK or inherit SDK defined on
the project level (see the SDK section later in this document). A
module can depend on other modules of the project.
Yes, it is ok for that SBT plugin for IDEA.
Usually IDEA project consists of top-level .idea directory (which contains configuration common to the project) and several *.iml files, one for each module in the project (module-specific configuration, like facets, excluded directories, custom dependencies). These files are usually located in the top-level directories of corresponding modules.
On the other hand, SBT plugin does something unusual. It creates standard .idea directory, but it stores all project modules in one location, namely .idea_modules directory in the top-level directory of the project. This is fully supported by IDEA project structure, which is a set of XMLs after all.
As for project directory/module, it is a standard feature of SBT builds. It contains your build configuration. See SBT manual on this.
The foregoing was about SBT plugin which is currently present in plugins repo. There is an official SBT plugin in active development which keeps familiar modules structure (no .idea_modules directory) and has higher integration with SBT. The latter is most prominent in dependency management - official plugin extracts dependencies, even unmanaged, and makes them available for the IDE; current SBT plugin cannot do that.
Related
Newcomer to the Intellij IDE here, with no Java background. I've looked at Build Definition to get a brief idea on how should I organize my scala files, but their example doesn't cover the full structure of an SBT-based project shown attached.
Can you advise what each folder should be used for (e.g. where my source files should go, etc.) and also point me to sources where I can go read up more.
Thanks so much
It is described pretty well here:
http://www.scala-sbt.org/0.13.5/docs/Getting-Started/Directories.html
But to sum up.
.idea:
This contains the project files for your idea project, and has nothing directly to do with sbt itself. However idea (if auto refresh is enabled) updates its own project, each time the sbt build files change.
project:
This contains the sbt project files, except for the main build file (files ending in .sbt). Sbt build is itself based on scala, and if you need to have some scala code included in your build (e.g., code-generation/meta-programming, pre-compiler macros), then you can place scala source files in this directory. The code of these files can be used in your build system, and is not part of your project itself. To really understand how a build is made, then you will need to understand the difference in how sbt files and scala files for the build should be placed. When you run sbt, then it will search for .sbt files in the directory your are standing in, when these are found, it will search for scala files in the project directory. These files together are the source of the build system, but because these are source files, they need to be built before they can be used. To build this build system, sbt uses sbt. So a build system to build the build system is needed. It therefore looks for sbt files inside the project directory, and scala files for this build inside project/project and build these files to get a build system, that can build the build system (that can build your project). Actually it can continue recursive down to any project/project/project... directory, until it finds a project folder containing no scala files, and therefore needs no building before use.
The target folder inside project, is the target folder for the sbt build of your build definition. See below what a target folder is.
Normally you would not need to be concerned about this; just remember that build.sbt in your root directory is the build script for your project. project/plugins.sbt defines plugins activated for your build system, and project/build.properties contains special sbt properties. Currently the only sbt property I now of, is what version of sbt should be used.
src:
This is where your place the source files of your project. You should place any java sources in src/main/java, scala sources in src/main/scala. Resources are placed in src/main/resources.
The src/main/scala_2.11 folder is typically used, if you have some code that it not binary compatible with different versions of scala. In such cases you would be able to configure sbt to use different source files when building for different versions of scala. You probably do not need this, so I would advise to just delete the src/main/scala_2.11 folder.
Test sources are placed inside src/test/java and source/test/scala, and test resources are placed in src/test/resources.
target
This folder is the target folder for sbt. All compiled files, generated packages and so on are placed somewhere inside this dir.
Most things in this dir are not so interesting, as most of it is just internal sbt things. However if your build a jar file by calling sbt package, then it will be placed inside target/scala-x (where x is the scala version). There are also a lot of different plugins, that can package your application in different ways, and they will normally also place the package files somewhere inside the target dir.
I'm trying to add the apache commons email library to my Play project and I'm having trouble.
Firstly I have both build.sbt and plugins.sbt in my project and I'm not sure which one I should be putting the import into, does anyone know?
Also, I'm not sure why there even is the separate project module in my project, intelliJ created it as part of the project. Could anyone explain the purpose of the two separate modules and why they are there?
Thanks!
So, in sbt, you have your project. This is specified in build.sbt (or more correctly, any *.sbt file in your projects base directory). Any libraries that your applications code needs, for example, if your application needs to send emails using the commons email library, go in to the librarDependencies seeing in here.
But build.sbt itself is Scala code that needs to be compiled, but it's not part of your applications runtime. So in sbt, your projects build is a project itself, one that has to be compiled. It has its own classpath, which consists of the sbt plugins you're using, so for example, if you need a less compiler to compile your less files, that's not something that gets done at runtime, so you don't want your application code depending on that, it goes into your project builds libraryDependencies, which gets specified in project/plugins.sbt (or in fact any *.sbt in the project directory). So, once you add it there, you can use the Scala code it provides from build.sbt. IntelliJ imports this project for you so that you can have syntax highlighting and other IDE features in build.sbt.
But it doesn't stop there. How does project/plugins.sbt get compiled, where is its classpath? Well, your projects builds projects builds project is also an sbt project itself too... It keeps going down. IntelliJ stops at that point though, it doesn't keep importing these meta sbt projects because it's actually very rare to need additional sbt plugins for your projects builds projects builds project, so it just uses the same classpath as your projects build project for syntax highlighting in project/plugins.sbt.
I have a multi-project SBT build: some projects are dependent on each other, some are dependent on third-party JARs, and there's a "main" project which depends on everything .
When I sbt package it, I get one JAR in each target/ directory.
What I want to achieve is getting all relevant JARs (mine and external) is one directory. Very similar to the way you package a WAR with Maven.
(And to clarify - I'm not interested in an assembled "FAT JAR" that contains all the dependencies in a single file. Just one directory with all JARs in it)
Im not 100% sure about the suprobject dependencies but I think SBT native packager should help you do something like that, and will also provide a start-script for windows and unixes:
http://www.scala-sbt.org/sbt-native-packager/GettingStartedApplications/MyFirstProject.html
I would recommend sbt-pack for creating self-contained JARs:
https://github.com/xerial/sbt-pack
I use it and haven't seen a glitch so far.
It also generates both OS X/Linux as well as Windows .bat entry scripts for the main classes/objects you choose.
When sharing a project with team members through version control, it is customary to include the .project in the source under version control. This makes sure that others on the team get all the dependencies and resources for the project. But the .project uses full/rooted paths to the resource, and not all members of a team will be working in the same environment. Even if all the members are on the same platform, the paths can often be in the user's home directory.
For the .classpath file, we can get around this problem by using build path variables. Each member defines the path to location of dependent libraries on their system, and the .classpath only refers to the variable.
This is a particular concern for Grails project - when we add a plugin, it updates the .project accordingly.
IMO resources themselves should not be part of the project at all. There is excellent plugin called m2eclipse which simplifies such tasks using Maven. It will immensely simplify your dependency management. All you'd have to keep in your version control system, besides your source code, is project configuration (pom.xml) - all the dependencies will be downloaded and cached automatically no matter what environment developer works in. There a lot more advantages in this approach - just read up on it :)
UPDATE: Just noticed "grails" tag on your question. if you're using Groovy - Maven can be replaced with Gradle. STS is probably the best Eclipse build to use if you're coding in Groovy. Next version of STS will have Gradle support.
General Approach
As others have mentioned, you should not keep the IDE files in VCS, you should keep an IDE-agnostic description of the project in VCS and generate the IDE-specific project files from them.
Java-Maven Example
Keep the pom.xml file(s) in VCS and generate the Eclipse files by running mvn eclipse:eclipse
Grails Example
A Grails project is described by application.properties and grails-app/conf/BuildConfig.groovy. These files are present in every Grails application. You can generate the Eclipse project descriptions from them by running:
grails integrate-with --eclipse
This command also supports other tools such as IntelliJ and Textmate
I don't think its standard practice to include the project file. I personally tell my VCS to ignore all IDE files, and just use VCS for the source. I include at the root level a README telling others how to configure the project (e.g. jars are in lib)
The resource links feature that you are referring to also has ability to use path variables. These are defined under Preferences -> General -> Workspace -> Linked Resources.
You could try keeping the project files in a shared Dropbox with an agreed upon path for each developer.
I have a dependency on clj-record in my CounterClockwise project. What's the best way to manage this? Copy the source code or compile to a JAR and add it as a referenced library?
There are tools to help you:
http://github.com/technomancy/leiningen <- project based
http://github.com/liebke/cljr <- dependencies not project based
http://github.com/ninjudd/cake <- alternative build tool
Assuming your dependencies are available in a Maven repo (like central or clojars), you have a couple of options.
First, if you're using Leiningen, there is an eclipse plugin for it now that will manage project dependencies for you, based on the dependencies you define in your project.clj file. The plugin is in beta now, but has been working great for me so far. (Note that it uses Leiningen 2.0 under the covers, though that detail won't matter for many (most?) simple cases.)
If you're using Maven, the m2eclipse plugin makes it so that the dependencies you declare in your Maven pom.xml are automatically added to your eclipse project's build path, and are therefore available in CCW REPLs and such.
there seems to be no pattern for specifying dependencies apart from hacking the code into your project or building a jar externally.
Of course you can, just as with any java project. While dependency resolution isn't tied into eclipse (yet), once you retrieve the deps (via one of the command line tools nickik listed), you can specify which jars are to be included in the java build path of your eclipse project:
Retrieve the deps via cake, leiningen, etc.
Refresh the eclipse project so you see the deps (usually in the lib directory)
Highlight the jars you want eclipse to know about
Right-click, select Build Path > Add to Build Path
That's it. You can fiddle with the build path by going to the Java Build Path section of the project's properties window.