| 24 Mar 2022 |
 zzyzzyxx#4150 | gotcha. version := 0.0.1-SNAPSHOT or whatever should also do the trick | 18:37:41 |
|  Bill Frasure joined the room. | 19:06:11 |
| Bill Frasure | Hey all, I'm working on zio-test, and having some difficulty generating Test reports correctly.
For ZIO 2.0, we are collecting all of the ZIOSpec classes in the entire project, composing them into a single ZIOSpec and then executing them as 1 large entity.
This does not align with SBT's expectation that 1 Spec == 1 Task, but I have been able to work around that for every situation aside from the XML reports.
I was hoping that I could return new Task s in our execute method that would process events with the correct EventHandler and then we would get 1 report per Spec.
So,
ASpec.xml
BSpec.xml
CSpec.xml
However, it appears that SBT is doing some tracking of whether a Task was generated by another Task, so instead I am getting:
ASpec.xml
ASpec-0.xml
Aspec-0-0.xml
So my question - is it possible to prevent SBT from tracking this, and instead treat each returned Task as a completely isolated entity? | 19:06:12 |
|  Daenyth#7233 joined the room. | 19:11:53 |
| Bill Frasure | Interesting, this is the first that I've seen that project.
I will try to dig around their codebase; thanks | 19:48:54 |
|  raz changed their display name from raz to raz#5324. | 19:52:54 |
| raz changed their display name from raz#5324 to raz. | 19:52:56 |
|  velvetbaldmime#6377 joined the room. | 20:25:47 |
| velvetbaldmime#6377 | Actually, in Weaver we collect all the specs into separate SBT Tasks and just orchestrate the results/logging/resource management in parallel across tests | 20:25:47 |
| velvetbaldmime#6377 | So in the end we emit as many Tasks as there are specs, so they should be getting individual reports. | 20:26:20 |
|  derya joined the room. | 20:33:23 |
| Bill Frasure | Thanks for the info, Would you mind pointing me to the relevant places in the code? | 20:36:52 |
| velvetbaldmime#6377 | Haven't touched that part in a while, but if I squint I can see the discovered suites being matched 1:1 to SBT's tasks: https://github.com/disneystreaming/weaver-test/blob/master/modules/framework/src-jvm/RunnerCompat.scala#L83-L108
Plus the task for the global resource management | 20:40:59 |
| velvetbaldmime#6377 | this stuff is hard to introspect so I can't say for certain that weaver generated the xml files you want 🙂 | 20:41:36 |
|  BitStrap joined the room. | 20:46:12 |
| Bill Frasure | Thanks, that gives me some ideas! | 20:56:16 |
|  alynel joined the room. | 22:33:15 |
| 25 Mar 2022 |
|  gapry joined the room. | 05:57:19 |
|  CU joined the room. | 10:38:01 |
|  Zachiah joined the room. | 21:06:08 |
|  Joram joined the room. | 21:29:27 |
| 26 Mar 2022 |
|  cuddle_puddle joined the room. | 18:07:34 |
| 27 Mar 2022 |
|  Desperate Lomov joined the room. | 10:32:24 |
|  nafg#1263 joined the room. | 22:27:08 |
| nafg#1263 | I have a complicated code generation process. Putting code in packages in project/ is iffy: | 22:27:09 |
| nafg#1263 | 1) sourcesInBase is not recursive, so sbt would need it to be under /project/src/main/scala | 22:27:34 |
| nafg#1263 | 2) IntelliJ doesn't understanding it in src/main/scala, but does understand (IIUC) packages in project/ | 22:28:08 |
| nafg#1263 | Ideally perhaps I would put the code in its own library but then I would need extra build / CI steps | 22:28:31 |
| 28 Mar 2022 |
|  O( N logN) joined the room. | 05:06:14 |
|  Tirpalas joined the room. | 09:16:25 |
