Enable (automated) instrumentaion of self

[matanox]

The integration test currently does not work for a self copy of this repo:

[info] Resolving canve#compiler-plugin_2.11;0.0.1 ...
[warn] circular dependency found: canve#simple-graph_2.11;0.0.1->canve#compiler-plugin_2.11;0.0.1->...
[warn] circular dependency found: canve#compiler-plugin_2.11;0.0.1->canve#simple-graph_2.11;0.0.1->...

This may be automatically resolved by #3, or possibly simpler to solve after #3 has been solved, so it would be wasteful to address this before #3, so it would be wasteful to address this before it.

[matanox]

Actually running on self may be accomplished relying on a previously published, or especially published clone version, of the artifacts.

[matanox]

Relying on a differently published version does not allow the sbt plugin to instrument a clone of the project: symbols still collide:

[info] Updating {file:/repos/canve/extractor/}canveSbtPlugin...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Compiling 24 Scala sources to /repos/canve/extractor/compiler-plugin/target/scala-2.10/classes...
[error] uncaught exception during compilation: java.lang.AssertionError
[trace] Stack trace suppressed: run last canveCompilerPlugin/compile:compileIncremental for the full output.
[error] (canveCompilerPlugin/compile:compileIncremental) java.lang.AssertionError: assertion failed: 
[error]      while compiling: /repos/canve/extractor/compiler-plugin/src/main/scala/util/index.scala
[error]         during phase: jvm
[error]      library version: version 2.10.4
[error]     compiler version: version 2.10.4
[error]   reconstructed args: -classpath /repos/canve/extractor/compiler-plugin/target/scala-2.10/classes:/repos/canve/extractor/simple-logging/target/scala-2.10/classes:/repos/canve/extractor/simple-graph/target/scala-2.10/classes:/home/matan/.ivy2/cache/io.circe/circe-core_2.10/jars/circe-core_2.10-0.2.1.jar:/home/matan/.ivy2/cache/org.typelevel/export-hook_2.10/jars/export-hook_2.10-1.0.2.jar:/home/matan/.ivy2/cache/org.typelevel/macro-compat_2.10/jars/macro-compat_2.10-1.0.4.jar:/home/matan/.ivy2/cache/org.scalamacros/quasiquotes_2.10/jars/quasiquotes_2.10-2.1.0-M5.jar:/home/matan/.ivy2/cache/org.spire-math/cats-core_2.10/jars/cats-core_2.10-0.2.0.jar:/home/matan/.ivy2/cache/org.spire-math/cats-macros_2.10/jars/cats-macros_2.10-0.2.0.jar:/home/matan/.ivy2/cache/com.github.mpilquist/simulacrum_2.10/jars/simulacrum_2.10-0.4.0.jar:/home/matan/.ivy2/cache/org.spire-math/algebra_2.10/jars/algebra_2.10-0.3.1.jar:/home/matan/.ivy2/cache/org.spire-math/algebra-std_2.10/jars/algebra-std_2.10-0.3.1.jar:/home/matan/.ivy2/cache/org.typelevel/machinist_2.10/jars/machinist_2.10-0.4.1.jar:/home/matan/.sbt/boot/scala-2.10.5/lib/scala-reflect.jar:/home/matan/.ivy2/cache/io.circe/circe-generic_2.10/jars/circe-generic_2.10-0.2.1.jar:/home/matan/.ivy2/cache/com.chuusai/shapeless_2.10/bundles/shapeless_2.10-2.2.5.jar:/home/matan/.ivy2/cache/io.circe/circe-parse_2.10/jars/circe-parse_2.10-0.2.1.jar:/home/matan/.ivy2/cache/io.circe/circe-jawn_2.10/jars/circe-jawn_2.10-0.2.1.jar:/home/matan/.ivy2/cache/org.spire-math/jawn-parser_2.10/jars/jawn-parser_2.10-0.8.3.jar:/home/matan/.ivy2/cache/com.lihaoyi/pprint_2.10/jars/pprint_2.10-0.3.6.jar:/home/matan/.ivy2/cache/com.lihaoyi/derive_2.10/jars/derive_2.10-0.3.6.jar:/home/matan/.ivy2/local/canve/simple-graph_2.10/0.0.1/jars/simple-graph_2.10.jar:/home/matan/.ivy2/local/com.github.tototoshi/scala-csv_2.10/1.3.0-SNAPSHOT/jars/scala-csv_2.10.jar:/home/matan/.ivy2/cache/org.scala-lang/scala-compiler/jars/scala-compiler-2.10.4.jar:/home/matan/.ivy2/local/canve-self-test-artifacts/compiler-plugin_2.10/0.0.1/jars/compiler-plugin_2.10.jar:/home/matan/.ivy2/local/canve-self-test-artifacts/simple-logging_2.10/0.0.1/jars/simple-logging_2.10.jar:/home/matan/.ivy2/local/canve-self-test-artifacts/simple-graph_2.10/0.0.1/jars/simple-graph_2.10.jar -bootclasspath /usr/lib/jvm/java-8-oracle/jre/lib/resources.jar:/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar:/usr/lib/jvm/java-8-oracle/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jsse.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jce.jar:/usr/lib/jvm/java-8-oracle/jre/lib/charsets.jar:/usr/lib/jvm/java-8-oracle/jre/lib/jfr.jar:/usr/lib/jvm/java-8-oracle/jre/classes:/home/matan/.ivy2/cache/org.scala-lang/scala-library/jars/scala-library-2.10.4.jar
[error] 
[error]   last tree to typer: Literal(Constant(canve-data))
[error]               symbol: null
[error]    symbol definition: null
[error]                  tpe: String("canve-data")
[error]        symbol owners: 
[error]       context owners: class index -> package util
[error] 
[error] == Enclosing template or block ==
[error] 
[error] Template( // val <local index>: <notype> in class index, tree.tpe=org.canve.util.index
[error]   "java.lang.Object" // parents
[error]   ValDef(
[error]     private
[error]     "_"
[error]     <tpt>
[error]     <empty>
[error]   )
[error]   DefDef( // def <init>(): org.canve.util.index in class index
[error]     <method>
[error]     "<init>"
[error]     []
[error]     List(Nil)
[error]     <tpt> // tree.tpe=org.canve.util.index
[error]     Block( // tree.tpe=Unit
[error]       Apply( // def <init>(): Object in class Object, tree.tpe=Object
[error]         index.super."<init>" // def <init>(): Object in class Object, tree.tpe=()Object
[error]         Nil
[error]       )
[error]       ()
[error]     )
[error]   )
[error] )
[error] 
[error] == Expanded type of tree ==
[error] 
[error] ConstantType(value = Constant(canve-data))
[error] 
[error] how can getCommonSuperclass() do its job if different class symbols get the same bytecode-level internal name: org/canve/compilerPlugin/package$DataNormalizationException

This pops up as an assertion and only fails on the mentioned symbol by random - overall it highlights that a separately published artifact will introduce the same symbol name hierarchy, regardless of its different org name (or package name? in this attempt only a different org name was used). Is it then impossible to introduce a separately versioned artifact in our involved case? looks like the only way is to derive, manually, a clone of the project where package names are modified by hand (or do this with a very ugly additional plugin that changes the package names on the fly before publishing, as part of a special run; it is actually more sensible doing this with a text parsing utility app than go down that path).

Such a separate parsing-laden app could also automate the entire process:

• duplicate the repo
• modify all package definition and reference strings (are references that easy to parse?)
• publishLocal
• clone the original repo again
• instrument it (as the integration test project does)
• run canve
• publish to website or whatever, later.

Otherwise tinkering scala/sbt to manage two versions of the same qualified module name seems to grope the darkest corners of them which nobody really cares about 👎