Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 22 2015 11:10
    japgolly commented #2066
  • Jun 22 2015 08:25
    keepscoding commented #2044
  • Jun 21 2015 03:24
    xerial commented #157
  • Jun 21 2015 00:10
    eed3si9n unlabeled #2057
  • Jun 21 2015 00:10

    eed3si9n on 0.13

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 3 more (compare)

  • Jun 21 2015 00:10
    eed3si9n closed #2057
  • Jun 21 2015 00:10

    eed3si9n on fixbuild

    (compare)

  • Jun 20 2015 18:42
    eed3si9n synchronize #2057
  • Jun 20 2015 18:42

    eed3si9n on fixbuild

    Fix typo (compare)

  • Jun 20 2015 18:23

    eed3si9n on fixbuild

    Adds bundledLauncherProj to all… Remove launcher tests Add unit tests to Travis and 1 more (compare)

  • Jun 20 2015 18:23
    eed3si9n synchronize #2057
  • Jun 20 2015 14:59

    eed3si9n on scalaversionbump

    (compare)

  • Jun 20 2015 14:59

    eed3si9n on 0.13

    Bumping up Scala version to 2.1… Try to keep bincompat Fixes #1666 and 1 more (compare)

  • Jun 20 2015 14:59
    eed3si9n unlabeled #2068
  • Jun 20 2015 14:59
    eed3si9n closed #2068
  • Jun 20 2015 14:59
    eed3si9n closed #1666
  • Jun 20 2015 14:57
    eed3si9n commented #2068
  • Jun 20 2015 12:55
    dwijnand commented #2068
  • Jun 20 2015 04:51
    eed3si9n synchronize #2068
  • Jun 20 2015 04:51

    eed3si9n on scalaversionbump

    Fixes #1666 (compare)

Jose C
@jmcardon
@jvican removing recursive build.sbt definitions
wherein you have to recurse into folders
Jorge
@jvican
No way, that's impossible
First, that's not a different style, it's a feature
Second, that's the foundation for the way plugins work
Jose C
@jmcardon
I mean... different build.sbt files in different folders
not so much the plugins
Jorge
@jvican
Ah, so then I wouldn't call it recursive build definition
Jose C
@jmcardon
my bad on the wording then
This is partly what causes a rift so hard when having any discussions as to how to do things in sbt. Essentially supporting many different ways of doing the same thing
Jorge
@jvican
No worries, that was a misunderstanding
So I think that's very contentious, because what do you do with multiple .sbt files in a directory?
Dale Wijnand
@dwijnand
You keep those, imo.
Being able to define a gitignored local.sbt is useful.
Jorge
@jvican
Yes, you have to... every build in the wild uses differnt sbt files in project
Dale Wijnand
@dwijnand
yeah that too
Jose C
@jmcardon
I think different .sbt files in a top level project is fine. Not so much in different ones in many different directories adding to the hackery that needs to be done for that to work
eugene yokota
@eed3si9n
I'd love to see this topic captured as a GitHub issue
Jose C
@jmcardon
I thought it was a tad broad for an issue
Jorge
@jvican
I think Scala Contributors is fine for this
It will get more outreach
Jose C
@jmcardon
I opted for discussion first so the community could think about what exactly constitutes an issue in this
eugene yokota
@eed3si9n
I am guessing that the original idea was that each subdir could exist as a build on its own
but it quickly breaks down with plugins
Jorge
@jvican
@jmcardon so the hackery that needs to be done for that to work won't disappear because it's required for recursive builds to work
Dale Wijnand
@dwijnand
and build.properties
Jorge
@jvican
but i agree with the sentiment of removing multiple sbt files in recursive dirs that are not project
Dale Wijnand
@dwijnand
also at the beginning of sbt files you couldn't define projects in them, so you couldn't have single top-level build.sbt style
Jose C
@jmcardon
I don't mean the actual procedure in the tool, just the style
This topic is rather broad so excuse my difficulty in nailing the wording just right
Jorge
@jvican
Don't worry, it's fine :) We're getting somewhere
Jose C
@jmcardon
Mostly I think the gains of this would be lowering the barrier of entry into sbt in general
I think beginners to sbt are quite flooded with all that there is to the tool on top of the fact that looking @ different projects doesn't help because their definitions can be so wildly different
Jorge
@jvican
Yes, I agree on the last point
I don't see any technical difficulty in doing so
I will comment on the Scala Contributors thread later on :)
Jose C
@jmcardon
Converging on one style lowers this, gives opportunity for more docs on a specific style and converges, with time, maintained projects into one way wherein it's easy to pick up where someone else left off
Jorge
@jvican
Gitter is not the great medium to discuss this, lots of people are missing out :P
Jose C
@jmcardon
Oh definitely, I just wanted to give some background on gitter for the ones already here :P
Jorge
@jvican
thanks :)
Jose C
@jmcardon
I'll come back to the discussion when it's developed a bit more
No problem
Sukant Hajra
@shajra
I just noticed a lot of people putting the same version they put in scalaVersion also in crossScalaVersions. But it just occurred to me that it might be convenient to have them as disjoint sets? But I can't exactly put it to words. It seems kind of annoying when building everything to have to write ; command ; + command
I think there's not a right/wrong answer... just curious if people have already thought about it.
eugene yokota
@eed3si9n
the logical end of that line is sbt-doge
s3ni0r
@s3ni0r
Hi everyone, i have a custom resolver in my build.sbt file that's not challenged when resolving dependecies :
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn]     ::          UNRESOLVED DEPENDENCIES         ::
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn]     :: com.spingo#op-rabbit-core_2.11;1.2.1: not found
[warn]     ::::::::::::::::::::::::::::::::::::::::::::::
[warn] 
[warn]     Note: Unresolved dependencies path:
[warn]         com.spingo:op-rabbit-core_2.11:1.2.1 (/builds/root/xxxxx/build.sbt#L115)
[warn]           +- xxxxxx-commons:xxxxxx-commons_2.11:1.0
[info] 'compiler-interface' not yet compiled for Scala 2.11.7. Compiling...
[info]   Compilation completed in 8.421 s
sbt.ResolveException: unresolved dependency: com.spingo#op-rabbit-core_2.11;1.2.1: not found
    at sbt.IvyActions$.sbt$IvyActions$$resolve(IvyActions.scala:291)
    at sbt.IvyActions$$anonfun$updateEither$1.apply(IvyActions.scala:188)
    at sbt.IvyActions$$anonfun$updateEither$1.apply(IvyActions.scala:165)
    at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:155)
    at sbt.IvySbt$Module$$anonfun$withModule$1.apply(Ivy.scala:155)
    at sbt.IvySbt$$anonfun$withIvy$1.apply(Ivy.scala:132)
    at sbt.IvySbt.sbt$IvySbt$$action$1(Ivy.scala:57)
    at sbt.IvySbt$$anon$4.call(Ivy.scala:65)
    at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:93)
    at xsbt.boot.Locks$GlobalLock.xsbt$boot$Locks$GlobalLock$$withChannelRetries$1(Locks.scala:78)
    at xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:97)
    at xsbt.boot.Using$.withResource(Using.scala:10)
    at xsbt.boot.Using$.apply(Using.scala:9)
    at xsbt.boot.Locks$GlobalLock.ignoringDeadlockAvoided(Locks.scala:58)
    at xsbt.boot.Locks$GlobalLock.withLock(Locks.scala:48)
    at xsbt.boot.Locks$.apply0(Locks.scala:31)
    at xsbt.boot.Locks$.apply(Locks.scala:28)
    at sbt.IvySbt.withDefaultLogger(Ivy.scala:65)
    at sbt.IvySbt.withIvy(Ivy.scala:127)
    at sbt.IvySbt.withIvy(Ivy.scala:124)
    at sbt.IvySbt$Module.withModule(Ivy.scala:155)
    at sbt.IvyActions$.updateEither(IvyActions.scala:165)
    at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1369)
    at sbt.Classpaths$$anonfun$sbt$Classpaths$$work$1$1.apply(Defaults.scala:1365)
    at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$87.apply(Defaults.scala:1399)
    at sbt.Classpaths$$anonfun$doWork$1$1$$anonfun$87.apply(Defaults.scala:1397)
    at sbt.Tracked$$anonfun$lastOutput$1.apply(Tracked.scala:37)
    at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1402)
    at sbt.Classpaths$$anonfun$doWork$1$1.apply(Defaults.scala:1396)
    at sbt.Tracked$$anonfun$inputChanged$1.apply(Tracked.scala:60)
    at sbt.Classpaths$.cachedUpdate(Defaults.scala:1419)
    at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1348)
    at sbt.Classpaths$$anonfun$updateTask$1.apply(Defaults.scala:1310)
    at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
    at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
    at sbt.std.Transform$$anon$4.work(System.scala:63)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
    at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:226)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
    at sbt.Execute.work(Execute.scala:235)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
    at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:226)
    at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
    at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
[error] (crawlerCommons/*:update) sbt.ResolveException: unresolved dependency: com.spingo#op-rabbit-core_2.11;1.2.1: not found
i can't figure out why this is happening
these are my resolvers :
resolvers ++= Seq(
      Resolver.sonatypeRepo("snapshots")
      ,Resolver.sonatypeRepo("releases")
      ,Resolver.typesafeRepo("releases")
      ,"spray repo" at "http://repo.spray.io"
      ,"SpinGo OSS" at "http://spingo-oss.s3.amazonaws.com/repositories/releases"
    )
and this what i got as warning messages that confirms the issue :
[info] Resolving com.spingo#op-rabbit-core_2.11;1.2.1 ...
[warn]     module not found: com.spingo#op-rabbit-core_2.11;1.2.1
[warn] ==== local: tried
[warn]   /root/.ivy2/local/com.spingo/op-rabbit-core_2.11/1.2.1/ivys/ivy.xml
[warn] ==== local-preloaded-ivy: tried
[warn]   /root/.sbt/preloaded/com.spingo/op-rabbit-core_2.11/1.2.1/ivys/ivy.xml
[warn] ==== local-preloaded: tried
[warn]   file:////root/.sbt/preloaded/com/spingo/op-rabbit-core_2.11/1.2.1/op-rabbit-core_2.11-1.2.1.pom
[warn] ==== public: tried
[warn]   https://repo1.maven.org/maven2/com/spingo/op-rabbit-core_2.11/1.2.1/op-rabbit-core_2.11-1.2.1.pom
Ghost
@ghost~540393fe163965c9bc2018ce
omg I wish for parallel scripted so much :cry: