cvogt / cbt Goto Github PK

cbt will not have a real interactive mode by design (which is a good thing because stateless is better than stateful), but could give an illusion of one that allows people to not type the prefix.

# non interactive mode
$ cbt foo
...
$ cbt bar
...
# fake interative mode
$ cbt
cbt> foo
...
cbt> bar
...

I've seen that you seem to like to have README:s in txt but in my opinion using markdown makes the project more accessible and inviting :)

Preview: https://github.com/tobias-johansson/cbt

What do you think?

https://github.com/xerial/sbt-sonatype

current work around is not stacking, which prevents caching maven jars and means performance issue. Would love to look into this together @bvenners

Loop runs continuously and doesn't seem to watch for file changes.

for comparison https://github.com/sbt/launcher/tree/1.0/project
https://github.com/sbt/launcher/tree/1.0/launcher-implementation/src/main/scala/xsbt/boot

That's because BarbaryWatchService can only watch directories. The watch library function should ignore files in those that weren't watched, but apparently that doesn't happen.

classloaders seem to be the keyword

e.g. https://github.com/eishay/jvm-serializers/blob/master/tpc/src/serializers/SimpleClassLoader.java

would be nice to have something that removes the target directory. I am slightly worried about adding a rm -rf equivalent at this point thought, because if we mess up paths, it may go horribly wrong and delete user files

In order to have reproducibility, builds probably should be able to specify a version of CBT they should be compiled with. One option would be a build.properties file just like SBT does it.

CBT would need to download the appropriate CBT version in order to compile a given build.

Also, CBT is extended via traits. How does that relate to different CBT versions. If CBT releases version 1.1, can users use plugins developed for 1.0 if they are compatible in some way (source or binary)? How?

@tpolecat would be great to have a session about this tomorrow. @milessabin this sort of falls into the category of compiling different typelevel libraries together, which I assume would not upgrade CBT all at the exact same time, so maybe we can join or overlap this session with that session.

if compile looping is given a path to a file rather than a folder, it currently watches the files parent folder, which is wrong in case of a top-level file in a project, which leads to CBT watching the whole toplevel folder including the target folder into which it generates the class files

https://github.com/sbt/sbt-houserules

Ran cbt without nailgun installed and got...

$ ./cbt
(Note: nailgun not found. It makes CBT faster! Try 'brew install nailgun'.)
Starting up nailgun
Recompiling CBT BootstrapScala.java
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-library/2.11.7/scala-library-2.11.7.jar
to /Users/matt/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-library-2.11.7.jar
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.11.7/scala-compiler-2.11.7.jar
to /Users/matt/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-compiler-2.11.7.jar
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.11.7/scala-reflect-2.11.7.jar
to /Users/matt/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-reflect-2.11.7.jar
downloading https://repo1.maven.org/maven2/org/scala-lang/modules/scala-xml_2.11/1.0.5/scala-xml_2.11-1.0.5.jar
to /Users/matt/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-xml_2.11-1.0.5.jar
Recompiling CBT. Detected source changes...
Stopping nailgun
Restarting nailgun

I will admit that I killed this before seeing whether or not it continued. Paused for a few minutes so that's probably something to check. But either way, we probably shouldn't be doing nailgun related things if we detect it isn't there.

assigning tentatively to milestone 1.1, but happier to get it in earlier

write a plugin for it

When trying to use something we forgot to add to our dependencies or we forgot to import, it would be nice to get some help into figuring out what exactly. This project may be a piece of the puzzle, allowing to get information from Maven: https://github.com/ChavXO/MavenSearch/

http://doc.scalatest.org/2.2.4/#org.scalatest.run$

The presented version at NEScala slightly differs from the released version in that the released version runs zinc more often than needed. This should be an easy fix which would basically entail detecting the return code of zinc and acting appropriately. Details in my head, hopefully solved soon enough to not be explained here

The README says sbt doesn't allow lazy dependencies. This is false, sbt does so allow lazy dependencies:

val flag = taskKey[Boolean]("a flag")
val taskA = taskKey[Unit]("task a")
val taskB = taskKey[Unit]("task b")
val dependentTask = taskKey[Unit]("dependent task")

taskA := println("task a")
taskB := println("task b")
flag := true

dependentTask <<= (flag, taskA.task, taskB.task).flatMap { (flag, a, b) =>
  if (flag) a else b
}

Running it shows that tasks A and B are lazily depended on:

> dependentTask
task a
> set flag := false
> dependentTask
task b
> 

currently NailgunLauncher uses lambda

may be helpful links
https://vectorbeta.wordpress.com/2014/08/26/the-java-logging-quagmire/

it keeps re-running indefinitely, which is wrong

there has been some superficial dirtiness been introduced in the last two days enhancements under time pressure. Let's clean that up.

It would be nice to install cbt easily

• mac
  • brew install cbt
• linux
  • apt-get
  • nix
  • yum
  • ...
• window
  • chocolatey
  • msi

http://stackoverflow.com/questions/6671913/scala-scripts-in-windows-batch-files
http://alvinalexander.com/scala/scala-shell-script-example-exec-syntax

Step towards moving the code into the typed world and getting it to work with windows shell as well.

http://mvnrepository.com/artifact/com.jsuereth/gpg-library_2.10
https://github.com/sbt/sbt-pgp/blob/v1.0.0/pgp-plugin/src/main/scala/com/typesafe/sbt/SbtPgp.scala
https://docs.oracle.com/javase/tutorial/deployment/jar/signing.html

http://www.programcreek.com/java-api-examples/index.php?api=org.apache.maven.model.building.ModelBuilder

https://github.com/sbt/sbt-pom-reader/blob/2b5fdc81b9d161dd70f3a716f3353e0ef308a83d/src/main/scala/com/typesafe/sbt/pom/MyModelResolver.scala

http://mvnrepository.com/artifact/org.apache.maven/maven-model-builder/3.3.3

https://www.google.ca/search?q=maven+getEffectiveModel&oq=maven+getEffectiveModel&aqs=chrome.0.69i59.3542j0j7&sourceid=chrome&es_sm=91&ie=UTF-8

http://stackoverflow.com/questions/11674537/retrieving-maven-artifact-from-repository-using-maven-java-api

for the reasons outlined in http://fommil.github.io/scalasphere16/

There are a few different indentation strategies used throughout the source. Some things are using tabs, others are using spaced. @cvogt Which is intended? :)

applies to git repos, private maven repos, sonatype api, bintray, etc.

see sbt/sbt#2496 and the catch-all https://issues.scala-lang.org/browse/SI-9683

There are multiple use cases for re-configuring a build at runtime. E.g. appending "-SNAPSHOT" to the version number when deploying a snapshot. Or changing the scalaVersion for cross-builds. It is not obvious how to do this, because CBT builds are classes where things are hard wired after instantiation if members are final. More concretely, this isn't possible:

class Build ... {
  def publishSnapshot{
    this.version = this.version + "-SNAPSHOT"
    publish
  }
}

Candidate solutions are

1. exposing selected fields like the through the constructor and providing via cli mechanism that fills them in (easy to implement, easy to work with, limited to hard coded use cases)

2. mutable members (easy to implement, tricky to work with, probably not a good idea)

3. providing users with a general purpose runtime mixins mechanism (hard to implement, easy to work with). Could look like this

   class BasicBuild(...){
     def publishSnapshot: Unit = {
       val reconfiguredBuild = this.mixin(
         new BasicBuild{
           override def version = super.version+“-SNAPSHOT”
         }
       ): reconfiguredBuild
       b.publish
     }
   }

4. Hard-coding something like 3, but specific to CBT (slightly less hard to implement, easy to work with, less universal). It would look at what's given and generate a trait that overrides exactly those fields. E.g. if a version is given via the command line, CBT would create build objects like this

   class DynamicOverrides{
     override def version = super.version+“-SNAPSHOT”
   }
   new Build(...) with DynamicOverrides

   Or if the user needs to override things, there could be an api to do so:

   val reconfiguredBuild = this.replace( version = this.version+"-SNAPSHOT" )

   or

   val reconfiguredBuild = (this.version = this.version+"-SNAPSHOT")

   or

   val reconfiguredBuild = this.version.set(this.version+"-SNAPSHOT")

   All of these would need to be magical of course, turning the given expression into the right hand side of a def of a mixed in trait.

5. On the Typelevel front people are considering creating an alternative frontend (which CBT supports), that is not based on inheritance, but a state monad instead. Would be interesting to see how that would look like and how it would differ from SBT's state monad

currently licences accepts any (String, Url)

this causes a complete mess in practice:
https://github.com/metadoc/metadoc/tree/develop/observations/licences

I would suggest something like:

trait License { // << not sealed
  def url: Url
  def toString: String
}
Apache2
MIT
AGPL
GPL2
GPL3
LGPL
MPL2
BSD
// ...

Nix uses this approach: https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix#L1 (spdx standard)

Workaround: Crtl+C and rerun

Asked by @tpolecat on gitter ( https://gitter.im/cvogt/cbt?at=56db6fa9a54928411668ac17 ):
how do I diagnose cbt hanging forever at Waiting for nailgun to start...?

bash ./cbt clean
/usr/bin/java -server -jar /usr/local/Cellar/nailgun/0.9.1/libexec/nailgun-server-0.9.1.jar 127.0.
ng --nailgun-port 4444 cbt.NailgunLauncher cbt.Stage1 /Users/rnorris/Scala/cbt/stage1/target/scala

To diagnose this:
All the nailgun related output is piped into nailgun_launcher/target/nailgun.stderr.log and nailgun_launcher/target/nailgun.stdout.log

http://martiansoftware.com/lab/jar2sh

low priority

I think right now, in a multi project build, tasks may not be properly propagated between dependent builds.

probably using nailgun as zinc uses https://github.com/typesafehub/zinc

related to #3

See also: #29

> javac -version 
javac 1.7.0_95
> cbt run
(Note: nailgun not found. It makes CBT faster! Try 'brew install nailgun'.)
Starting up nailgun
Recompiling CBT BootstrapScala.java
/home/tobias/Projects/cbt/bootstrap_scala/BootstrapScala.java:38: error: illegal start of expression
            Arrays.stream(ds).forEach( d -> {
                                          ^
[ ... lots of javac errors ... ]

JDK version >= 8 should probably be checked in the launcher bash script to print a more helpful error message

https://docs.oracle.com/javase/tutorial/essential/io/notification.html

see http://bioportal.weizmann.ac.il/course/prog2/tutorial/deployment/jar/ex5/JarClassLoader.java

We may be able to support some or all SBT plugins fully or in a limited fashion by programatically turning CBT builds into SBT builds and then executing tasks on them. Not sure that's actually possible because the wiring of CBT builds is by method calls and can't be explored programatically unless we have TASTY or do some macro annotation magic (which may actually be fine for sbt interop).

This is definitely worth exploring i order to tap on the solutions for use cases already implemented as SBT plugins.

Any opinions on this @clhodapp @MasseGuillaume

Clean bootstrap on 5488e70 (problem not present on c2f53c5)
(Ubuntu, javac 1.8.0_66-internal, OpenJDK Runtime Environment (build 1.8.0_66-internal-b17))

> cbt run
(Note: nailgun not found. It makes CBT faster! Try 'brew install nailgun'.)
Recompiling CBT BootstrapScala.java
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-library/2.11.7/scala-library-2.11.7.jar
to /home/tobias/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-library-2.11.7.jar
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-compiler/2.11.7/scala-compiler-2.11.7.jar
to /home/tobias/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-compiler-2.11.7.jar
downloading https://repo1.maven.org/maven2/org/scala-lang/scala-reflect/2.11.7/scala-reflect-2.11.7.jar
to /home/tobias/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-reflect-2.11.7.jar
downloading https://repo1.maven.org/maven2/org/scala-lang/modules/scala-xml_2.11/1.0.5/scala-xml_2.11-1.0.5.jar
to /home/tobias/Projects/cbt/bootstrap_scala/cache/2.11.7/scala-xml_2.11-1.0.5.jar
Recompiling NailgunLauncher. Detected source changes.
Stopping nailgun
Restarting nailgun
Recompiling Stage1. Detected source changes.
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
    at cbt.NailgunLauncher.main(NailgunLauncher.java:42)

• #364
• #365
• #274
• #146
• #366
• #367
• #368
• #369
• #316
• #370
• #371
• #372
• #373
• #377
• #279

It would be great to be able to embed projects built with SBT as subprojects into CBT builds. This will allow to depend on SBT projects by source, (once we have GIT dependencies, which I'll start working on tonight).

This shouldn't be too hard actually. A cbt.Dependency subclass that delegates to a SBT build under the hood should do it.

Somebody with solid SBT knowledge wanna pick this up :)? @clhodapp @MasseGuillaume ?