stevedlawrence commented on pull request #681: URL: https://github.com/apache/daffodil/pull/681#issuecomment-976461723
> Even better, let's stop comparing the old example files to the new example files and just update them unconditionally during "sbt compile" like we update all the other automatically generated files. Even if we autocompile, it still doesn't guarantee that those files are committed. Devs still need to `git add` those files. If they use `git add .` or something similar that will happen, but it's dev workflow dependent. I personally use `git add -p` or manually add files I know I've modified--I don't think it would even cross my mind to commit changes I didn't personally make if I was new to this. Since it's still possible that a PR is made without actually updating these files depending on a dev's workflow, I'd prefer that we still have a test somewhere, even if we unconditionally rebuild these when compiling. A one line github action could do this. > Make "sbt compile" call genExamples automatically, otherwise we have to type genExamples at sbt prompt This is fine with me. Note that this is a bit different than the existing auto generators. Ideally this would be a `sourceGenerator` or a `resourceGenerator`. But the output of a `sourceGenerator` I think needs to be compilable Scala or Java. And `resourceGenerators` aren't run with sbt compile, they are run some other time during the packaging prcoess. So things are a bit different. However, things get a bit tricky. We can still trigger a task to run during compilation without using a generator, but we have to be careful about task dependency cycles. The way the genExample needs to work is it essentially just forks a java process and executes the CLI with the right arguments. But this task depends on the CLI (and all of its dependencies being compiled), so this task really can't live in the CLI or any of its dependent subprojects (e.g. `daffodil-runtime2` or the root `daffodil` project), or we'll get circularity issues. That probably also means that what this task generates probably shouldn't be in any of those projects either--even if it works, generating a file inside another subproject feels dangerous and might confuse sbt, or create subtle issues. So, what if we moved the runtime2 generated example files into the tutorials subproject? The genExamples task would also live in the `tutorials` project, and then the example files are just resources that get generated and committed in the tutorials subproject? > Add log4j-core to genExamples' classpath so we don't get "ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console..." I've got some changes that I think should fix this. Do you mind if I push the changes to your PR once I get things working? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
