Confused and Frustrated by SBT

[kraythe]

Greetings, I have spent a decent amount of time reading around the Scala world about using SBT with multi-module builds and I have to confess total confusion. There are many articles on how to do it. All which seem to be using deprecated versions of the SBT tool with features and procedures completely out of date. The SBT documentation itself seems to assume that you already know SBT really well to teach you how to do things in SBT which is ... odd ... to say the least. I found the docs to be cryptic and rely on a lot of assumptions that are simply not true for the beginner with SBT. As a result I keep hearing SBT is the best tool to build scala but I am having a heck of a time setting up what would be trivial with maven or gradle. Simply this. 

I have a project A which has two Subprojects B and C. Project C depends upon the code of project B. I want to be able to build A, B or C independently. So if I build A, it should build B and C, if I build B or C individually, they should only be built without requiring to build dependent projects. So I could farm out B to a team and C to a team and they would choose when to integrate new features in B. In maven this is exceedingly simple. In SBT, I have read so many contradictory things that to this date I have no clue how to accomplish it. 

SBT may be a rocking good tool, I will take the community's word for it, but it has a nasty learning curve and the documentation for getting started doesn't take you much beyond the most trivial build. So you have a learning gap akin to K through 6th grade is well documented but then there is nothing until doctoral level. 

In conclusion I have a suggestion and request: 

The suggestion is that the documentation really needs to plug that gap and since there is all sorts of deprecated docs and articles on the internet, it needs to do so on the SBT site to avoid confusion. Google here is a hinderance, not an asset. 

The request is on a more practical question of how the heck do I accomplish my goals with the current version of SBT?

Thanks in advance.

[Jason Zaugg]

On Mon, Feb 17, 2014 at 7:45 PM, kraythe <kra...@gmail.com> wrote:

Greetings, I have spent a decent amount of time reading around the Scala world about using SBT with multi-module builds and I have to confess total confusion. There are many articles on how to do it. All which seem to be using deprecated versions of the SBT tool with features and procedures completely out of date. The SBT documentation itself seems to assume that you already know SBT really well to teach you how to do things in SBT which is ... odd ... to say the least. I found the docs to be cryptic and rely on a lot of assumptions that are simply not true for the beginner with SBT. As a result I keep hearing SBT is the best tool to build scala but I am having a heck of a time setting up what would be trivial with maven or gradle. Simply this. 

I have a project A which has two Subprojects B and C. Project C depends upon the code of project B. I want to be able to build A, B or C independently. So if I build A, it should build B and C, if I build B or C individually, they should only be built without requiring to build dependent projects. So I could farm out B to a team and C to a team and they would choose when to integrate new features in B. In maven this is exceedingly simple. In SBT, I have read so many contradictory things that to this date I have no clue how to accomplish it. 

I think that's cutting against the grain in SBT. It isn't really typically to change inter-sub-project dependendies from internal (ie, from source) to external (from -SNAPSHOT JARs).

I believe you can rig it up with something like [1]. Hopefully someone else on the list can help out to confirm that this is the right tool.

-jason

[1] http://stackoverflow.com/questions/8330149/in-sbt-how-do-i-specify-a-project-dependency-on-another-possibly-independent-s

[Josh Suereth]

Yeah, sbt isn't really designed with that use case in mind.  What you could do, from the console perhaps, is remove the `project-resolver` from the list of `fullResolvers` as well as removing the other projects from the fullClasspath.  This should both remove the locally compiled projects from the classpath *AND* force Ivy to resolve the projects remotely.

If this feature is really vital for your workflow, please open an enhancement ticket to make it simpler.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Josh Suereth]

Also, as far as the documentation is concerned, we've definitely heard that request a lot.  Not only am I authoring a book on sbt, our goal for the next major release (1.0) is to revamp the docs to ease the learning curve.   If you have any suggestions on areas you'd like to see, please let us know.

[Sonnenschein]

Josh, we do eagerly await more progress on your Manning publication. Hope there will be no halt...

[Josh Suereth]

It's been touch and go working on sbt (and its documentation) vs. the book.  However, you should see a new chapter 10 with the next meap. I'm pretty excited about this one.

On Mon, Feb 17, 2014 at 2:32 PM, Sonnenschein <peter...@arcor.de> wrote:

Josh, we do eagerly await more progress on your Manning publication. Hope there will be no halt...

--

[kraythe .]

So everyone using snt keeps all their code in one great big hair ball? That is not a valid work flow in my opinion. Or do they do something else to achieve separation of projects?

--

Robert Simmons Jr. MSc. - Lead Java Architect @ EA

Author of: Hardcore Java (2003) and Maintainable Java (2012)

LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39

[Sonnenschein]

You may achieve separation/dependencies by any combination of

• defining one or more multi-projects
  
• publishing your subprojects to an enterprise repository in order other projects resolve them from there
• placing subprojects in different source code repositories
• configuring local copies to fit the requirements of farmed out teams
  
• ...(?)

So I admit I don't really understand your issue. Maybe it helps if you provide something more concrete.

I have a project A which has two Subprojects B and C. Project C depends upon the code of project B. I want to be able to build A, B or C independently. So if I build A, it should build B and C...

I'm a bit confused. If the latter holds, why do you call it an independent build?

Peter

[pagoda_5b]

Hi Josh,

Is there an expected release date for v.1.0 ? Or is everything still work in progress?

Thanks

Ivano

[Kevin Wright]

On 18 February 2014 00:00, kraythe . <kra...@gmail.com> wrote:

So everyone using sbt keeps all their code in one great big hair ball? That is not a valid work flow in my opinion. Or do they do something else to achieve separation of projects?

I've found that the opposite is generally true.

If you need to work on stuff in separate teams, then you manage the code as entirely independent projects with dependencies handled at a binary level via maven/ivy resolution.

It's attempting to shoehorn things into a single project/codebase that causes hairballs.

[Kevin Scaldeferri]

On Tuesday, February 18, 2014 4:06:15 AM UTC-8, Kevin Wright wrote:

On 18 February 2014 00:00, kraythe . <kra...@gmail.com> wrote:

So everyone using sbt keeps all their code in one great big hair ball? That is not a valid work flow in my opinion. Or do they do something else to achieve separation of projects?

I've found that the opposite is generally true.

If you need to work on stuff in separate teams, then you manage the code as entirely independent projects with dependencies handled at a binary level via maven/ivy resolution.

It's attempting to shoehorn things into a single project/codebase that causes hairballs.

 

Agreed, we have hundreds of independent SBT projects in their own repositories.  Some are "simple" SBT projects, some are multi-projects (for things like server and client libraries which we want to release together).

We have a "meta"-plugin which all these projects use which aggregates a number of other plugins, does a lot of default configuration, and implements some of our custom functionality (like additional release steps).

[kraythe]

I don't have a problem having them be completely separate projects. What I haven't seen is a way to glue them together. So In maven I would have project B have a pom file and push its deployable library to a repository and then have project C depend on that deployable via artifactID, groupID and version. Yet in SBT i don't see how I would push anything to a local repository or otherwise put it where it could be found. I suppose I could have a pom and use maven to do that, or ivy and ant, but then what would be the point of SBT if I have to use Maven anyway. The documentation around this is very sketchy. SBT doesn't have its own repository I gather? How do I do the equivalent of mvn install for local binary installation or mvn deploy for remote upload to something like artifactory. 

Try goggling "sbt multi module build" and see the massive amount of contradictory information. And if you stick with the SBT site there is not enough official documentation. 

Very frustrating. I want to spend time working on my app, not fighting a build system. Tempted to go back to gradle or maven. 

-- Robert

[Jason Zaugg]

On Tue, Feb 18, 2014 at 7:42 PM, kraythe <kra...@gmail.com> wrote:

I don't have a problem having them be completely separate projects. What I haven't seen is a way to glue them together. So In maven I would have project B have a pom file and push its deployable library to a repository and then have project C depend on that deployable via artifactID, groupID and version. Yet in SBT i don't see how I would push anything to a local repository or otherwise put it where it could be found. I suppose I could have a pom and use maven to do that, or ivy and ant, but then what would be the point of SBT if I have to use Maven anyway. The documentation around this is very sketchy. SBT doesn't have its own repository I gather? How do I do the equivalent of mvn install for local binary installation or mvn deploy for remote upload to something like artifactory. 

Try goggling "sbt multi module build" and see the massive amount of contradictory information. And if you stick with the SBT site there is not enough official documentation. 

Very frustrating. I want to spend time working on my app, not fighting a build system. Tempted to go back to gradle or maven. 

Use `publishLocal` to publish to a developer local repository in ~/.ivy2, and `publish` to deploy to a remote repository.

Docs: http://www.scala-sbt.org/release/docs/Detailed-Topics/Publishing.html

-jason

[Roland Kuhn]

Hi Robert,

we do this all the time; have you checked this?

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn

[Josh Suereth]

On Tue, Feb 18, 2014 at 6:58 AM, pagoda_5b <ivano....@gmail.com> wrote:

Hi Josh,

Is there an expected release date for v.1.0 ? Or is everything still work in progress?

1.0 is feature-based, not time-based.  The 0.13.x releases are more time-based.  However, 0.13.2 has been delayed as you'll see a preview of new 1.0-ish features in there.  

Primarily coming in sbt 0.13.2:

* AutoPlugins + Project natures (what we expect will help dramtically in plugin authoring and consuming, as well as give us nicer error messages when a plugin is not wired to a project correctly).

* Name-Hashing incremental compiler

* Various "hooks" in keys that the sbt-server will make use of

* Ability for the sbt-launcher to launch/lock "services" (or servers) rather than just applications.

* .previous on TaskKeys to load last computed result.

Sbt 1.0 preliminary features:

* Sbt as a Server/Service  

   - Single sbt instance per "build".  Clients startup/connect and issue commands.

   - Sbt terminal becomes a client

   - IDE integration directly to server (working with Eclipse team, and in talks with IntelliJ as things progress)

   - Coordination between things like Play run compilation + IDE compilation

   - Remote Process management API so things like forked tests can have attached debuggers/etc.

* Revamped Documentation

   - Architecture/Design docs as an "after the getting started" path

   - Expanded Javadoc/Scaladoc API comments.

   - Getting Started tutorial projects/activator templates.

The big feature here being the sbt server.  Lots of work going on in the `sbt-remote-control` project on a prototype implementation right now. So, 1.0 is reliant upon that to be complete.

One thing I *wish* I could write on the feature list is "Dropping Ivy for better dependency management solution".  Unfortunately, my preliminary research isn't going so well here.  That may have to be a 1.1 or later feature, given the state of things.  We'll continue the train of "can we make Ivy incrementally better" we've been riding.

Hope that helps!

- Josh

[Josh Suereth]

On Tue, Feb 18, 2014 at 1:42 PM, kraythe <kra...@gmail.com> wrote:

I don't have a problem having them be completely separate projects. What I haven't seen is a way to glue them together. So In maven I would have project B have a pom file and push its deployable library to a repository and then have project C depend on that deployable via artifactID, groupID and version. Yet in SBT i don't see how I would push anything to a local repository or otherwise put it where it could be found. I suppose I could have a pom and use maven to do that, or ivy and ant, but then what would be the point of SBT if I have to use Maven anyway. The documentation around this is very sketchy. SBT doesn't have its own repository I gather? How do I do the equivalent of mvn install for local binary installation or mvn deploy for remote upload to something like artifactory. 

Try goggling "sbt multi module build" and see the massive amount of contradictory information. And if you stick with the SBT site there is not enough official documentation. 

Very frustrating. I want to spend time working on my app, not fighting a build system. Tempted to go back to gradle or maven. 

What may be needed here is a "guide to sbt for maven users".  If i understand correctly, you're using parent poms to denote an entire build in maven, and want to load a small sub-project of that build and be able  build it.

IN sbt, a given build file defines one or more projects.  If you want to share settings between projects, you can do so via a shared plugin of settings rather than by inheriting from a parent pom.  So, in sbt the hierarchy is always:

Build -> Project -> tasks/settings

WHile in maven, the build is an OO model where "parent direcory" and "parent build" are conflated.   In sbt, re-using settings is as easy as publishing an artifact that has the definitions and then Builds can consume that downstream.  (Some argue that publishing artifacts is not easy in a nexus world, I agree).

Once you have a multi-module sbt build, you can run an individual project's build via its name:

`sbt <project>/task`.

By default all tasks are aggregated on subprojects, but this is optional.   HOWEVER, if you have subprojects in your build, we assume this is because they are compiled/delivered together.  Also, by having specfic knowledge of the task-level dependencies between these interrelated projects, we can optimise how tasks are run across all of them, at a more global level than is available to maven just because we have the knowledge of when 's safe to do so.

Sbt is designed such that all projects in a build are *cohesive*.  You can still keep things modular quite easily, since you have compilation separation.  More so than if you have one massive build where it's hard to detangle any part of it.   As such, for very large projects, sbt is designed to parcel them out into coherent pieces, as it is now.   Ideally, with time, we'll have ways to deal with massive projects using clever loading and what not, but for now, we'd rather have the build environment have a good usage experience (things like ~, testQuick, parallel execution by default) and wrap smaller sbt projects together via integration builds, such as the community build we have.

Hope that helps explain.

- Josh

[Rich Oliver]

What I'd really appreciate is if  we could have documentation of how to write the basic configurations in Scala. For example, here's a basic build.sbt file:
_________________________________
name := "StratLib"

version := "0.0.1"

libraryDependencies += "org.scalatest" % "scalatest_2.10" % "1.9.1" % "test"

scalaSource in Compile := file("src")

scalaSource in Test := file("test")

resourceDirectory in Compile <<= baseDirectory(_ / "resources")

unmanagedSourceDirectories in Compile <++= baseDirectory { base =>
  Seq(
  base / "../prUtil/src",
  base / "srcMain"
  )
  }

mainClass := Some("pGrid.pCons.StratConsApp")

artifactName := { (sv: ScalaVersion, module: ModuleID, artifact: Artifact) => "Strat.jar" }
________________________

Can anyone tell us how I could get rid of the build.sbt file and write that in Scala? And while we're on it how do write the main jar artifact to the project base folder?

[Josh Suereth]

Perhaps we can document that a little better.

1. create a `project/build.scala` file

2. Contents:


import sbt._

import Keys._

import <the plugins you want to use that sbt will automatically import in .sbt files>._

object MyBuild extends Build {
  val root = Project("StratLib", file(".")).settings(

    ... rest of .sbt contents, comma separated ...

  )
}

Note: If you do that, you can still have project specific config in .sbt files.  Also, from your syntax, I assumed sbt 0.12.x rather than 0.13 syntax.

Why don't you open a ticket on sbt to cover the conceptual mapping from .sbt => .scala files.  We'll happily write it when we can.

- Josh

--

[kraythe]

Well there is some very good information on this thread and I hope it helps others in the future. I think the maven -> sbt guide would be a fantastic thing. It would have helped me tremendously. 

Honestly my adventure with SBT has had a number of pitfalls. I definitely have had problem with multi-module builds but also build files that are sensitive to whitespace (the double spaced lines) are very 80's sort of feel to me. Not since then have I worked with a computing tech that cared about whitespace, much less blank lines. I think one feedback I would have to the SBT team is to find some way of getting rid of that issue. I am not enough of a scala expert to even make a suggestion here. I would rather write a build.scala file then do a double spaced thing. In fact Gradle builds are essentially groovy scripts, why can't SBT do the same with scala scripts? 

At any rate I will see how I can progress with the extra info in the thread and thanks all for responding. 

[pagoda_5b]

Yep, excellent!

Ivano

[Josh Suereth]

On Tue, Feb 18, 2014 at 11:26 PM, kraythe <kra...@gmail.com> wrote:

Well there is some very good information on this thread and I hope it helps others in the future. I think the maven -> sbt guide would be a fantastic thing. It would have helped me tremendously. 

Honestly my adventure with SBT has had a number of pitfalls. I definitely have had problem with multi-module builds but also build files that are sensitive to whitespace (the double spaced lines) are very 80's sort of feel to me. Not since then have I worked with a computing tech that cared about whitespace, much less blank lines. I think one feedback I would have to the SBT team is to find some way of getting rid of that issue. I am not enough of a scala expert to even make a suggestion here. I would rather write a build.scala file then do a double spaced thing. In fact Gradle builds are essentially groovy scripts, why can't SBT do the same with scala scripts? 

We're on it:  https://github.com/sbt/sbt/wiki/Improving-.sbt-format-(take-2)#wiki-2-attempt-to-remove-the-blank-line-restrictions-via-an-improved-parser

In terms of having build scripts be "scala scripts", we're working back towards that.  Having builds be raw Scala files has its own set of problems that we decided to migrate away into a 'scala-like' DSL.   However, you *can* still use .scala for your build if desired, as I do for a  good number of my builds, like: https://github.com/sbt/sbt-remote-control/blob/master/project/build.scala

[kraythe]

Great to hear! I would be curious what the problems were with them being scala scripts. I have to say that is one of the things that attracted me to gradle for Java builds, is the ability, the flexibility to do things in the build file that maven doesn't allow without a plugin. Plugins are well and good but extremely heavyweight for one-offs or little tasks of only a few lines of code. I hope that in the future the SBT team maintains the ability to use .scala build files. 

One other thing I think you will have to get away from ivy for dependencies for all the reason that gradle got away from it. Snapshots being a problem among other things. Another thing I would like to see (which maybe is there, I don't know) is a good intraprocess communication API so editors like Emacs could be wired up to be integrated without having to go to java based libs or fancy tricks.

At any rate thanks for the info and If I knew as much about scala as I do about java Id jump in and help. :) It seems to have great promise. 

-- Robert

[Seth Tisue]

On Tue, Feb 18, 2014 at 11:26 PM, kraythe <kra...@gmail.com> wrote:

In fact Gradle builds are essentially groovy scripts, why can't SBT do the same with scala scripts? 

see http://stackoverflow.com/q/21780787/86485

--
Seth Tisue - se...@tisue.net - http://tisue.net

[Seth Tisue]

On Tue, Feb 18, 2014 at 7:06 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

If you need to work on stuff in separate teams, then you manage the code as entirely independent projects with dependencies handled at a binary level via maven/ivy resolution.

It's attempting to shoehorn things into a single project/codebase that causes hairballs.

+1

[Seth Tisue]

On Tue, Feb 18, 2014 at 7:57 PM, Rich Oliver <rzi...@gmail.com> wrote:

Can anyone tell us how I could get rid of the build.sbt file and write that in Scala?

This is an FAQ. A natural home for an answer would be Stack Overflow, but I don't see it there. Ask there? I suspect you'd get a good answer that would then become a resource for others.

The closest thing I can find is http://stackoverflow.com/questions/18000103/ but it's not really a how-to.

[Josh Suereth]

On Wed, Feb 19, 2014 at 10:53 AM, kraythe <kra...@gmail.com> wrote:

Great to hear! I would be curious what the problems were with them being scala scripts. I have to say that is one of the things that attracted me to gradle for Java builds, is the ability, the flexibility to do things in the build file that maven doesn't allow without a plugin. Plugins are well and good but extremely heavyweight for one-offs or little tasks of only a few lines of code. I hope that in the future the SBT team maintains the ability to use .scala build files. 

With the .sbt file format enhancements, if we lift the blank line restrictions, you should have pretty close support in your .sbt files with methods, values that you can define and re-use. You can also always create .scala files and use them in your .sbt files.   I'll try to document this a bit more somewhere coherently.   You're not that limited, but perhaps the .sbt blank-line restriction makes it feel that way.

 

One other thing I think you will have to get away from ivy for dependencies for all the reason that gradle got away from it. Snapshots being a problem among other things. Another thing I would like to see (which maybe is there, I don't know) is a good intraprocess communication API so editors like Emacs could be wired up to be integrated without having to go to java based libs or fancy tricks.

Funny enough, that's what I'm working on now (sbt-remote-control).

 

At any rate thanks for the info and If I knew as much about scala as I do about java Id jump in and help. :) It seems to have great promise. 

-- Robert

On Wednesday, February 19, 2014 9:00:09 AM UTC-6, Josh Suereth wrote:

On Tue, Feb 18, 2014 at 11:26 PM, kraythe <kra...@gmail.com> wrote:

Well there is some very good information on this thread and I hope it helps others in the future. I think the maven -> sbt guide would be a fantastic thing. It would have helped me tremendously. 

Honestly my adventure with SBT has had a number of pitfalls. I definitely have had problem with multi-module builds but also build files that are sensitive to whitespace (the double spaced lines) are very 80's sort of feel to me. Not since then have I worked with a computing tech that cared about whitespace, much less blank lines. I think one feedback I would have to the SBT team is to find some way of getting rid of that issue. I am not enough of a scala expert to even make a suggestion here. I would rather write a build.scala file then do a double spaced thing. In fact Gradle builds are essentially groovy scripts, why can't SBT do the same with scala scripts? 

We're on it:  https://github.com/sbt/sbt/wiki/Improving-.sbt-format-(take-2)#wiki-2-attempt-to-remove-the-blank-line-restrictions-via-an-improved-parser

In terms of having build scripts be "scala scripts", we're working back towards that.  Having builds be raw Scala files has its own set of problems that we decided to migrate away into a 'scala-like' DSL.   However, you *can* still use .scala for your build if desired, as I do for a  good number of my builds, like: https://github.com/sbt/sbt-remote-control/blob/master/project/build.scala

[Lee Mighdoll]

Agreed, we have hundreds of independent SBT projects in their own repositories.  Some are "simple" SBT projects, some are multi-projects (for things like server and client libraries which we want to release together).

We have a "meta"-plugin which all these projects use which aggregates a number of other plugins, does a lot of default configuration, and implements some of our custom functionality (like additional release steps).

 

Can you describe this meta plugin a bit more?  It sounds interesting.  (Or is it open source?)

Cheers,

Lee

[Kevin Scaldeferri]

Honestly, so much of it is specific to our workflow and particular operational choices that I don't think open sourcing it would be valuable, except perhaps as an example.  I have talked a bit more about it at a couple conferences, although at a fairly high level.

http://www.slideshare.net/kscaldef/innovating-faster-wsbtcdlxc

http://www.youtube.com/watch?v=EDbO47MKljQ

http://cufp.org/sites/all/files/slides/2013/scaldeferri.pdf

I should probably write up a little more about it, but maybe that's helpful at least as an inspiration.  Basically, our goal has been to require most of our developers to only have to worry about the slightest tip of sbt's full complexity by providing them with abstractions that match how we work.  Then only a couple people need to worry about how it all really works.

-kevin

[Josh Suereth]

Very cool stuff!

[Naftoli Gugenheim]

I suspect your question may have been  misunderstood. Please clarify:
Do you simply want to set up an sbt project with multiple subprojects that have various dependencies between each other?
Or do you specifically need that the projects can be used *both* as subprojects within one build, *and* as standalone projects whose interdependencies are only declared via libraryDependencies?
I believe your question sounded like you wanted the latter, but I suspect you really just want the former.

[Rex Kerr]

I personally need the latter, so a straightforward explanation (ideally: minimal example) of how to achieve the latter would be of interest to me also.  Use case: I have a huge hairball that is all the code I routinely need for research, but also have subprojects that I want to build separately, and want to be able to release independent of the rest of the mess.

I looked into setting this up via SBT just long enough to realize that I would have to look for much longer than I wanted to spend, or end up with multiple separate projects for the same code which invariably would get out of sync with each other.

  --Rex

[Naftoli Gugenheim]

It probably doesn't need to be said, but you can get part way there by keeping subprojects' settings in a .sbt file in the subproject directory. Perhaps there's some way to detect whether the current project is a subproject or not? If so you could have a conditional libraryDependencies += setting in there. There are probably a lot of issues that doesn't solve though.

[Josh Suereth]

So the one thing about sbt is that you havea  "build" as your entry point, but releasing sub-projects of software is somethign I do, for example, with the sbt-pgp plugin which includes a separate maven-released library for GPG-like behavior on top of bouncy castle.

Once you're in the sbt prompt for the "large" project, you only need to write:  <sub-project>/<task> *or* `project <sub-project>` to move your console into that project and do your work solely for that project.

Again, perhaps we have to include docs, but just because the projects have to share the same build definition doesn't mean you can't interact with them on an individual basis.  You just can't start the sbt prompt in a subdirectory and expect it to find the whole build definition.

On Wed, Feb 19, 2014 at 11:57 PM, Rex Kerr <ich...@gmail.com> wrote:

[kraythe]

While we are at it, I would love to have an annoying maven issue fixed n SBT. Lets say I have a two projects where project A depends on project B version 1.0.0. Id like to be able to declare that project A depends on project B version 2.0.0 and have the tool fetch either the release (if available) or the snapshot if there is no release available. Having to go back and retroactively change all dependencies in release is a bloody pain. 

[Josh Suereth]

If your projects are in the same build, you depend on them directly, so the version numbers are coordinated in that sense.

On Fri, Feb 21, 2014 at 3:04 PM, kraythe <kra...@gmail.com> wrote:

While we are at it, I would love to have an annoying maven issue fixed n SBT. Lets say I have a two projects where project A depends on project B version 1.0.0. Id like to be able to declare that project A depends on project B version 2.0.0 and have the tool fetch either the release (if available) or the snapshot if there is no release available. Having to go back and retroactively change all dependencies in release is a bloody pain. 

--

[kraythe .]

Not all my projects are identical. Such is the life in the business world. :) 

Robert Simmons Jr. MSc. - Lead Java Architect @ EA

Author of: Hardcore Java (2003) and Maintainable Java (2012)

LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39

[Robin Green]

I actually kind of like the fact that when you are building a release, if you have non-snapshot dependencies you know they really are releases, not snapshots masquerading as releases. Although I suppose this requirement could be enforced at the resolver level still, if you had that feature. You could have one resolver that is for releases and only picks up release dependencies, and another resolver that is for snapshots and picks up both snapshots and releases.

[kraythe .]

I wouldn't worry about that, you can always have warnings and separate repos or a flag that says "don't resolve snapshots" which is a fairly easy thing to configure for Continuous integration environments. 

Robert Simmons Jr. MSc. - Lead Java Architect @ EA

Author of: Hardcore Java (2003) and Maintainable Java (2012)

LinkedIn: http://www.linkedin.com/pub/robert-simmons/40/852/a39

--
You received this message because you are subscribed to a topic in the Google Groups "scala-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-user/a8CJUG3BmuA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scala-user+...@googlegroups.com.

[Stephen Compall]

On Wed, 2014-02-19 at 21:28 -0500, Naftoli Gugenheim wrote:
> Or do you specifically need that the projects can be used *both* as
> subprojects within one build, *and* as standalone projects whose
> interdependencies are only declared via libraryDependencies?

Maybe Robert is looking for something like this:

http://nocandysw.com/sbt-adhoc-subprojects-plugin

Be warned, I have not ported it to 0.13, because it has an odd
restriction over what kind of projects it supports: dependencies'
project/* contents are ignored, because only the root project gets to
load anything with project/*. This may work for some arrangements,
though.

Let me know if that's the case, and I might consider a port. It would
be better to have a solution to the project isolation problem before an
0.13 port, though.

--
Stephen Compall
"^aCollection allSatisfy: [:each | aCondition]": less is better than