Prototype implementation using Scala reflection to show accessible members when running cbt

[megri]

As things currently stand, running cbt shows "" for accessible members of Build but a whole bunch from CBT

[megri]

Those TypeTag[whatever] also feel like a leaky abstraction. Something should probably be done with those before considering a merge.

[megri]

Using one of the approaches mentioned here might do the trick: https://stackoverflow.com/questions/23785439/getting-typetag-from-a-classname-string

[cvogt]

so what's not working yet?

[cvogt]

I am still a little concerned about performance with this
and is scala reflection thread safe these days?

[megri]

I've updated the prototype and I'm now confused. It seems to partially work! But why? I've basically bludgeoned def taskMethods into frankenstein's method.

There seems to be some issues with calling tasks defined in the CBT scope at the moment — not sure why.

I believe scala reflection is still not thread safe. time cbt on a compiled project shows cbt 0,04s user 0,07s system 20% cpu 0,539 total on my Macbook Pro anno 2012.

[megri]

Comparison of running cbt on a simple project

before

Methods provided by Build(/Users/martin/dev/scala/cbt-test/splaintest)

dontShowMe  sausages



Methods provided by CBT (but possibly overwritten)

_context  buildInfoXml  c  classLoader  classLoaderCache  classes  classpath  clean  cleanFiles  compile  compileClasspath  compileDependencies  compileStatusFile  compileTarget  complete  context  crossScalaVersionsArray  defaultScalaVersion  dependencies  dependenciesArray  dependencyClasspath  dependencyClasspathArray  dependencyTree  docTarget  enableConcurrency  exportedClasspath  exportedClasspathArray  finalBuild  flatClassLoader  fork  generatedSources  getClass  hashCode  help  jarTarget  lastModified  lib  libraries  localJars  logger  mainClass  mainClassOrFail  moduleKey  name  needsUpdateCompat  nonEmptySourceFiles  notify  notifyAll  ports  projectDirectory  publish  r  recursive  repl  resourceClasspath  restart  rt  run  runForked  runForkedHandles  scalaMajorVersion  scalaTarget  scalaVersion  scalacOptions  scaladoc  show  sourceFiles  sources  t  target  targetClasspath  taskCache  test  toString  transientCache  transitiveDependencies  triggerLoopFiles  triggerLoopFilesArray  verifyClasspath  void  wait  zincVersion

after

Methods provided by Build(/Users/martin/dev/scala/cbt-test/splaintest)

sausages



Methods provided by CBT (but possibly overwritten)

artifactId  buildInfoXml  c  classLoader  classes  classpath  clean  cleanFiles  compile  compileClasspath  compileStatusFile  compileTarget  complete  context  crossScalaVersionsArray  defaultScalaVersion  dependencies  dependenciesArray  dependencyClasspath  dependencyClasspathArray  dependencyTree  description  developers  docJar  docTarget  enableConcurrency  exportedClasspath  exportedClasspathArray  finalBuild  flatClassLoader  fork  generatedSources  groupId  help  inceptionYear  jar  jarFilePrefix  jarTarget  lastModified  licenses  localJars  mainClass  mainClassOrFail  moduleKey  name  needsUpdateCompat  nonEmptySourceFiles  organization  package  pom  projectDirectory  publish  publishLocal  publishedArtifacts  r  recursive  repl  resourceClasspath  restart  rt  run  runForked  scalaMajorVersion  scalaTarget  scalaVersion  scalacOptions  scaladoc  scmConnection  scmUrl  show  sourceFiles  sources  srcJar  t  target  targetClasspath  test  toString  transientCache  transitiveDependencies  triggerLoopFiles  triggerLoopFilesArray  url  verifyClasspath  version  void  zincVersion

[Baccata]

Could this be achieved with something similar to ammonite's router ?

IE, when compiling the build, a macro could take care of aggregating the callable methods into a router that effectively acts as a single entry point to cbt. I assume this would create overhead when compiling the build would allow for safer method calls, allow for calling methods with arguments from the terminal